Подтверждения действий агента и безопасность

Codex помогает защитить ваш код и данные и снижает риск неправомерного использования.

По умолчанию агент работает с отключённым доступом к сети. При локальной работе Codex использует песочницу, ограничения которой обеспечиваются ОС: она ограничивает доступные агенту ресурсы (как правило, текущей рабочей областью). Кроме того, применяется политика подтверждений, определяющая, когда агент должен остановиться и запросить ваше разрешение перед выполнением действия.

Общее объяснение работы песочницы в настольном приложении ChatGPT, Codex CLI и расширении IDE см. в разделе Песочница. Более широкий обзор корпоративной безопасности представлен в техническом документе о безопасности Codex.

Переход с устаревшей политики одобрений untrusted

Codex и ChatGPT Work больше не поддерживают approval_policy = "untrusted". Устаревшая настройка может помешать запуску любого из этих клиентов. Удалите её из конфигурации пользователя или проекта, файлов профилей, скриптов запуска и централизованно управляемых настроек по умолчанию. Для интерактивной работы в режиме только для чтения используйте:

sandbox_mode = "read-only"
approval_policy = "on-request"

Или выполните codex --sandbox read-only --ask-for-approval on-request.

При on-request команды, разрешённые песочницей, могут выполняться без одобрения, читать доступные файлы и использовать сетевой доступ, если он включён.

Чтобы сохранить более строгое правило одобрения команд, не задавайте явно approval_policy и добавьте запись проекта в пользовательский файл ~/.codex/config.toml:

[projects."/path/to/project"]
trust_level = "untrusted"

Тогда команды требуют одобрения, если их не разрешает правило политики выполнения. Это также отключает локальную конфигурацию проекта. Явное указание on-request переопределяет политику, определяемую проектом; централизованно управляемый параметр allowed_approval_policies должен включать untrusted, чтобы разрешить её.

Песочница и подтверждения

Средства безопасности Codex состоят из двух совместно работающих уровней:

• Режим песочницы: какие действия Codex технически может выполнять (например, куда он может записывать данные и может ли обращаться к сети) при исполнении команд, созданных моделью.
• Политика подтверждений: когда Codex должен запросить ваше разрешение перед выполнением действия (например, перед выходом за пределы песочницы, использованием сети или запуском команд, не входящих в доверенный набор).

Codex использует разные режимы песочницы в зависимости от среды запуска:

• Codex cloud: работает в изолированных контейнерах под управлением OpenAI, что предотвращает доступ к основной системе и посторонним данным. Использует двухэтапную модель выполнения: настройка выполняется до этапа работы агента и может обращаться к сети для установки указанных зависимостей, после чего этап работы агента по умолчанию выполняется без сети, если для этой среды не включён доступ к интернету. Секреты, настроенные для облачных сред, доступны только во время настройки и удаляются до начала этапа работы агента.
• Codex CLI / расширение IDE: политики песочницы обеспечиваются механизмами уровня ОС. По умолчанию доступ к сети отключён, а разрешение на запись ограничено активной рабочей областью. Песочницу, политику подтверждений и параметры сети можно настроить с учётом допустимого для вас риска.

В предустановке Auto (например, --sandbox workspace-write --ask-for-approval on-request) Codex может автоматически читать файлы, вносить изменения и выполнять команды в рабочем каталоге.

Codex запрашивает подтверждение для изменения файлов за пределами рабочей области или выполнения команд, которым требуется доступ к сети. Если вы хотите общаться с агентом или составлять план без внесения изменений, переключитесь в режим read-only с помощью команды /permissions.

Codex также может запрашивать подтверждение для вызовов инструментов приложений (коннекторов), которые заявляют о побочных эффектах, даже если действие не является командой оболочки или изменением файла. Разрушительные вызовы инструментов приложений/MCP всегда требуют подтверждения, если инструмент помечен как разрушительный (кроме случаев, когда инструмент помечен как предназначенный для чтения: такая пометка имеет приоритет).

Мониторинг безопасности и приостановленные задачи

GPT-6 Astra включает мониторинг безопасности в Codex и ChatGPT Work. Мониторинг работает асинхронно и может приостановить задачу, если обнаружит потенциально небезопасное поведение модели. Приостановка может произойти уже после вызвавшего её действия; мониторинг не заменяет песочницу, разрешения или проверку результата.

Если задача приостановлена, прочитайте уведомление и изучите результаты проверки, когда они станут доступны. Возобновляйте работу только после того, как убедитесь в безопасности продолжения задачи. Если в уведомлении сказано, что задача завершена, или возможность возобновления отсутствует, продолжить её в этом интерфейсе нельзя.

Мониторинг безопасности оценивает поведение модели во время выполнения задачи. Автоматическая проверка подтверждений оценивает отдельные действия, которые уже требуют подтверждения, до их выполнения. Действие, разрешённое автоматической проверкой подтверждений, всё равно может относиться к задаче, которую мониторинг позднее приостановит.

Доступ к сети

Сведения о включении полного доступа к интернету или списка разрешённых доменов для Codex cloud см. в разделе Доступ агента к интернету.

В настольном приложении ChatGPT, Codex CLI и расширении IDE режим песочницы workspace-write по умолчанию оставляет доступ к сети отключённым, пока вы не включите его в конфигурации:

[sandbox_workspace_write]
network_access = true

Изоляция сети

Доступ к сети регулируется правилами назначений, которые применяются к скриптам, программам и подпроцессам, запускаемым командами. Если сетевой доступ для команд уже включён, включите функцию network_proxy, чтобы ограничить этот трафик настроенной сетевой политикой. Простое добавление правил доменов не включает прокси.

[features.network_proxy]
enabled = true
domains = { "api.openai.com" = "allow", "example.com" = "deny" }

Для разового сеанса CLI используйте сокращённую логическую форму, если требуется только переключатель, и табличную форму, если также задаются параметры политики:

codex \
  -c 'features.network_proxy=true' \
  -c 'sandbox_workspace_write.network_access=true'

codex \
  -c 'features.network_proxy.enabled=true' \
  -c 'features.network_proxy.domains={ "api.openai.com" = "allow", "example.com" = "deny" }' \
  -c 'sandbox_workspace_write.network_access=true'

Эта функция изменяет способ контроля уже включённого доступа к сети, но сама по себе не предоставляет его. Используйте конфигурацию sandbox_workspace_write.network_access с workspace-write, чтобы определить, разрешён ли командам доступ к сети вообще:

• Сеть отключена + network_proxy включено: сеть остаётся отключённой, а функция ничего не делает.
• Сеть включена + network_proxy отключено: сеть остаётся включённой с неограниченным прямым исходящим доступом.
• Сеть включена + network_proxy включено: сеть остаётся включённой, а исходящий трафик ограничивается настроенной сетевой политикой.

Функция прокси также применяется к профилям разрешений. Параметр профиля network.enabled = true предоставляет командам доступ к сети, а features.network_proxy = true включает принудительное применение правил доменов этого профиля:

default_permissions = "project-edit"

[features]
network_proxy = true

[permissions.project-edit]
extends = ":workspace"

[permissions.project-edit.network]
enabled = true

[permissions.project-edit.network.domains]
"api.openai.com" = "allow"

Если не включить функцию прокси в этом примере, команды получат прямой доступ к сети, а разрешающее правило api.openai.com не будет ограничивать доступные им назначения.

Управляемые администратором требования experimental_network не зависят от пользовательского переключателя функции. Они могут настроить и запустить изолированную сеть без features.network_proxy, но не включают доступ к сети, если он отключён активной песочницей. Формат администраторского параметра requirements.toml см. в разделе Управляемая конфигурация.

Сетевая политика

В правилах доменов приоритет отдаётся списку разрешений:

• Точные имена хостов соответствуют только самим себе.
• *.example.com соответствует поддоменам, таким как api.example.com, но не example.com.
• **.example.com соответствует как корневому домену, так и поддоменам.
• Глобальное разрешающее правило * соответствует любому публичному хосту, доступ к которому не запрещён. Считайте * широким доступом к сети и по возможности предпочитайте более узкие правила.
• deny всегда имеет приоритет над allow, а глобальное правило * допустимо только для разрешающих правил.

Локальные и частные назначения

По умолчанию allow_local_binding = false блокирует loopback-, link-local- и частные назначения:

• Точечные исключения: добавьте точный литерал локального IP-адреса или разрешающее правило localhost, когда команде требуется одно локальное назначение.
• Более широкий доступ: задавайте allow_local_binding = true только в том случае, если намеренно хотите предоставить более широкий локальный/частный доступ.
• Подстановочные знаки: правила с подстановочными знаками не считаются явными исключениями для локальных адресов.
• Разрешённые адреса: имена хостов, которые разрешаются в локальные/частные IP-адреса, остаются заблокированными, даже если соответствуют списку разрешений.

Защита от DNS rebinding

Перед разрешением имени хоста Codex выполняет максимально возможную проверку DNS и классификацию IP-адреса:

• Запросы, завершившиеся ошибкой или по тайм-ауту, блокируются.
• Имена хостов, разрешающиеся в непубличные адреса, блокируются.
• Проверка снижает риск DNS rebinding, но не устраняет его полностью. Для полной защиты от rebinding потребовалось бы закреплять разрешённые IP-адреса на транспортном уровне.

Если в рассматриваемую модель угроз входит враждебный DNS, обеспечьте контроль исходящего трафика также на более низком уровне.

Опасные настройки

Две настройки намеренно расширяют границы доверия:

• dangerously_allow_non_loopback_proxy = true может открыть доступ к прослушивающим адресам прокси за пределами loopback.
• dangerously_allow_all_unix_sockets = true позволяет обойти список разрешённых сокетов Unix.

Используйте их только в строго контролируемых средах. Когда проксирование сокетов Unix включено, прослушивающие адреса всё равно ограничены loopback, даже если запрошена привязка не к loopback, поэтому изолированная сеть не превращается в удалённый мост к локальным демонам.

network_proxy по умолчанию отключено. При включении:

Трафик вне сетевого прокси команд

Сетевой прокси фильтрует скрипты, программы и дочерние процессы, выполняемые в локальной песочнице команд. Он не фильтрует веб-поиск, вызовы инструментов приложений или коннекторов, подключения к серверам MCP, действия браузера или Computer Use, задачи Codex cloud, а также запросы клиента к модели и службе аутентификации. Для этих интерфейсов используются отдельные служебные подключения, настройки функций, политики рабочей области или средства управления средой.

Инструменты браузера отдельно проверяют управляемые запреты сети и исключительные списки разрешений перед обращением к источнику. Политики источников браузера могут дополнительно ограничивать доступ к сайтам, отправку и скачивание файлов, а также инструменты разработчика. См. раздел Управляемые средства браузера.

Для управляемых пользователей сочетайте сетевую политику команд с такими средствами управления, как allowed_web_search_modes, утверждённые mcp_servers и требования к функциям для приложений, плагинов, браузеров или Computer Use. См. раздел Управляемая конфигурация.

Вы также можете управлять инструментом веб-поиска, не предоставляя полного доступа к сети запускаемым командам. По умолчанию Codex получает результаты через кэш веб-поиска. Кэш представляет собой поддерживаемый OpenAI индекс веб-результатов, поэтому в кэшированном режиме возвращаются предварительно индексированные результаты без загрузки страниц в реальном времени. Это снижает подверженность внедрению подсказок из произвольного актуального содержимого, однако результаты поиска всё равно следует считать недоверенными. При использовании --yolo или другой настройки песочницы с полным доступом веб-поиск по умолчанию возвращает актуальные результаты. Используйте --search или задайте web_search = "live", чтобы разрешить просмотр актуальных страниц, либо задайте значение "disabled", чтобы отключить инструмент:

web_search = "cached"  # default
# web_search = "disabled"
# web_search = "live"  # same as --search

Задайте web_search = "indexed", если внешний веб-доступ должен ограничиваться поисковым индексом. Будьте осторожны при включении доступа к сети или веб-поиска в Codex. Внедрение подсказок может заставить агента получать и выполнять недоверенные инструкции.

Значения по умолчанию и рекомендации

• При запуске Codex определяет, используется ли в папке система управления версиями, и рекомендует:
  • Папки под управлением системы версий: Auto (запись в рабочую область + подтверждения по запросу)
  • Папки без системы управления версиями: read-only
• В зависимости от конфигурации Codex также может запускаться в режиме read-only, пока вы явно не укажете, что доверяете рабочему каталогу (например, в запросе первоначальной настройки или с помощью /permissions).
• Рабочая область включает текущий каталог и временные каталоги, такие как /tmp. Используйте команду /status, чтобы узнать, какие каталоги входят в рабочую область.
• Чтобы принять значения по умолчанию, выполните codex.
• Их также можно задать явно:
  • codex --sandbox workspace-write --ask-for-approval on-request
  • codex --sandbox read-only --ask-for-approval on-request

Защищённые пути в корнях с разрешённой записью

В стандартной политике песочницы workspace-write корни с разрешённой записью всё равно содержат защищённые пути:

• <writable_root>/.git защищён в режиме только для чтения независимо от того, является он каталогом или файлом.
• Если <writable_root>/.git — файл-указатель (gitdir: ...), разрешённый путь к каталогу Git также защищён в режиме только для чтения.
• <writable_root>/.agents защищён в режиме только для чтения, если существует как каталог.
• <writable_root>/.codex защищён в режиме только для чтения, если существует как каталог.
• Защита рекурсивна, поэтому всё содержимое этих путей доступно только для чтения.

Запуск без запросов подтверждения

Запросы подтверждения можно отключить с помощью --ask-for-approval never или -a never (сокращённая форма).

Эта настройка работает со всеми режимами --sandbox, поэтому вы по-прежнему управляете уровнем автономности Codex. Codex действует максимально эффективно в заданных вами ограничениях.

Если Codex должен читать файлы, вносить изменения и выполнять команды с доступом к сети без запросов подтверждения, используйте --sandbox danger-full-access (или флаг --dangerously-bypass-approvals-and-sandbox). Перед этим внимательно оцените риски.

В качестве промежуточного варианта approval_policy = { granular = { ... } } позволяет сохранить интерактивные запросы для отдельных категорий подтверждений и автоматически отклонять остальные. Детальная политика охватывает подтверждения песочницы, запросы правил execpolicy, запросы MCP, запросы request_permissions и подтверждения скриптов навыков.

Автоматическая проверка подтверждений

По умолчанию запросы подтверждения направляются вам:

approvals_reviewer = "user"

Автоматическая проверка подтверждений применяется, когда подтверждения интерактивны, например при approval_policy = "on-request" или детальной политике подтверждений. Задайте approvals_reviewer = "auto_review", чтобы направлять подходящие запросы подтверждения агенту-рецензенту до того, как Codex выполнит запрос:

approval_policy = "on-request"
approvals_reviewer = "auto_review"

Полное описание жизненного цикла рецензента, условий запуска, приоритетов конфигурации и поведения при сбоях см. в разделе Автоматическая проверка.

Рецензент оценивает только действия, уже требующие подтверждения, например повышение привилегий песочницы, заблокированные сетевые запросы, запросы request_permissions или вызовы инструментов приложений и MCP с побочными эффектами. Действия, не выходящие за пределы песочницы, продолжаются без дополнительной проверки.

Политика рецензента проверяет попытки вывода данных, поиска учётных данных, постоянного ослабления безопасности и разрушительные действия. Действия с низким и средним риском могут выполняться, если это разрешено политикой. Действия с критическим риском политика запрещает. Действия с высоким риском требуют достаточных полномочий от пользователя и отсутствия соответствующего запрещающего правила. Сбои при формировании запроса, сеансе проверки и разборе данных приводят к безопасному отказу. Тайм-ауты отображаются отдельно, но действие всё равно не выполняется.

Политика рецензента по умолчанию находится в репозитории Codex с открытым исходным кодом. Организации могут заменить её раздел для конкретного арендатора параметром guardian_policy_config в управляемых требованиях. Локальный текст [auto_review].policy также поддерживается, но управляемые требования имеют приоритет. Инструкции по настройке см. в разделе Управляемая конфигурация.

В настольном приложении ChatGPT такие проверки отображаются как элементы автоматической проверки со статусом «Проверяется», «Разрешено», «Отклонено», «Прервано» или «Истекло время ожидания». Они также могут содержать оценку уровня риска и полномочий пользователя для проверяемого запроса.

Автоматическая проверка использует дополнительные вызовы модели, поэтому может увеличивать расход ресурсов Codex. Администраторы могут ограничить её с помощью allowed_approvals_reviewers.

Распространённые сочетания песочницы и подтверждений

Для неинтерактивных запусков используйте codex exec --sandbox workspace-write; Codex сохраняет поддержку прежних вызовов codex exec --full-auto как устаревший путь совместимости и выводит предупреждение.

Конфигурация в config.toml

Более полное описание настройки см. в разделах Основы конфигурации, Расширенная конфигурация и Справочник по конфигурации.

# Interactive approvals with a read-only sandbox
approval_policy = "on-request"
sandbox_mode    = "read-only"
allow_login_shell = false # optional hardening: disallow login shells for shell-based tools

# Optional: Allow network in workspace-write mode
[sandbox_workspace_write]
network_access = true

# Optional: granular approval policy
# approval_policy = { granular = {
#   sandbox_approval = true,
#   rules = true,
#   mcp_elicitations = true,
#   request_permissions = false,
#   skill_approval = false
# } }

Предустановки также можно сохранить как файлы профилей, а затем выбирать их с помощью codex --profile profile-name:

# ~/.codex/full_auto.config.toml
approval_policy = "on-request"
sandbox_mode    = "workspace-write"

# ~/.codex/readonly_quiet.config.toml
approval_policy = "never"
sandbox_mode    = "read-only"

Локальная проверка песочницы

Чтобы увидеть, что происходит при выполнении команды в песочнице Codex, используйте следующие команды Codex CLI:

# macOS
codex sandbox macos [--permissions-profile <name>] [--log-denials] [COMMAND]...
# Linux
codex sandbox linux [--permissions-profile <name>] [COMMAND]...
# Windows
codex sandbox windows [--permissions-profile <name>] [COMMAND]...

Команда sandbox также доступна как codex debug, а у вспомогательных средств платформ есть псевдонимы (например, codex sandbox seatbelt и codex sandbox landlock).

Песочница уровня ОС

Codex реализует песочницу по-разному в зависимости от ОС:

• macOS использует политики Seatbelt и запускает команды с помощью sandbox-exec с профилем (-p), соответствующим выбранному режиму --sandbox. Когда ограниченный доступ на чтение включает стандартные настройки платформы, Codex добавляет тщательно подобранную политику платформы macOS (вместо широкого разрешения /System), чтобы сохранить совместимость с распространёнными инструментами.
• Linux по умолчанию использует bwrap вместе с seccomp.
• Windows использует реализацию песочницы Linux при запуске в Windows Subsystem for Linux 2 (WSL2). WSL1 поддерживалась до Codex 0.114; начиная с 0.115 песочница Linux перешла на bwrap, поэтому WSL1 больше не поддерживается. При нативном запуске в Windows Codex использует реализацию песочницы Windows.

Расширение Codex IDE в Windows напрямую поддерживает WSL2. Добавьте следующую настройку VS Code, чтобы агент всегда оставался внутри WSL2, когда эта среда доступна:

{
  "chatgpt.runCodexInWindowsSubsystemForLinux": true
}

Благодаря этому расширение IDE наследует семантику песочницы Linux для команд, подтверждений и доступа к файловой системе, даже если основной ОС является Windows. Подробнее см. в руководстве по WSL.

При нативном запуске в Windows настройте режим нативной песочницы в config.toml:

[windows]
sandbox = "unelevated" # or "elevated"
# sandbox_private_desktop = true  # default; set false only for compatibility

Подробнее см. в руководстве по настройке Windows.

При запуске Linux в контейнерной среде, например Docker, песочница может не работать, если конфигурация основной системы или контейнера блокирует пространство имён, setuid bwrap или операции seccomp, необходимые Codex.

В таком случае настройте контейнер Docker так, чтобы он обеспечивал необходимую изоляцию, а затем запустите codex с --sandbox danger-full-access (или флагом --dangerously-bypass-approvals-and-sandbox) внутри контейнера.

Запуск Codex в Dev Containers

Если основная система не может напрямую запустить песочницу Linux или ваша организация уже стандартизировала контейнерную разработку, запускайте Codex с Dev Containers и используйте Docker как внешнюю границу изоляции. Это работает с Visual Studio Code Dev Containers и совместимыми инструментами.

Используйте пример безопасного devcontainer для Codex как эталонную реализацию. В примере устанавливаются Codex, распространённые инструменты разработки, bubblewrap и средства управления исходящим трафиком на основе межсетевого экрана.

Эталонная реализация включает:

• базовый образ Ubuntu 24.04 с установленными Codex и распространёнными инструментами разработки;
• профиль межсетевого экрана для исходящего доступа на основе списка разрешений;
• настройки VS Code и рекомендации расширений для повторного открытия рабочей области в контейнере;
• постоянные точки подключения для истории команд и конфигурации Codex;
• bubblewrap, чтобы Codex мог по-прежнему использовать песочницу Linux, когда контейнер предоставляет необходимые возможности.

Чтобы опробовать её:

1. Установите Visual Studio Code и расширение Dev Containers.
2. Скопируйте пример конфигурации Codex .devcontainer в свой репозиторий или начните работу непосредственно с репозитория Codex.
3. В VS Code выполните команду Dev Containers: Open Folder in Container... и выберите .devcontainer/devcontainer.secure.json.
4. После запуска контейнера откройте терминал и выполните codex.

Контейнер также можно запустить из CLI:

devcontainer up --workspace-folder . --config .devcontainer/devcontainer.secure.json

Пример состоит из трёх основных частей:

• .devcontainer/devcontainer.secure.json управляет настройками и возможностями контейнера, точками подключения, переменными среды и расширениями VS Code.
• .devcontainer/Dockerfile.secure определяет образ на основе Ubuntu и установленные инструменты.
• .devcontainer/init-firewall.sh применяет политику исходящего сетевого доступа.

Эталонный межсетевой экран намеренно представляет собой лишь отправную точку. Если для изоляции вы полагаетесь на список разрешённых доменов, реализуйте подходящую для вашей среды защиту от DNS rebinding и обновления DNS, например обновление с учётом TTL или межсетевой экран с поддержкой DNS.

Внутри контейнера выберите один из следующих режимов:

• Оставьте песочницу Linux в Codex включённой, если профиль Dev Container предоставляет возможности, необходимые bwrap для создания внутренней песочницы.
• Если контейнер является предполагаемой границей безопасности, запустите Codex внутри него с --sandbox danger-full-access, чтобы Codex не пытался создать второй уровень песочницы.

Управление версиями

Codex лучше всего работает в рамках процесса управления версиями:

• Работайте в ветке функции и поддерживайте git status в чистом состоянии перед делегированием. Так изменения Codex будет проще изолировать и откатывать.
• Предпочитайте процессы на основе патчей (например, git diff/git apply) непосредственному редактированию отслеживаемых файлов. Часто создавайте коммиты, чтобы можно было откатывать небольшие порции изменений.
• Относитесь к предложениям Codex как к любому другому PR: выполняйте целевые проверки, просматривайте различия и фиксируйте решения в сообщениях коммитов для аудита.

Мониторинг и телеметрия

Codex поддерживает добровольно включаемый мониторинг через OpenTelemetry (OTel), помогающий командам проводить аудит использования, расследовать проблемы и выполнять требования нормативов без ослабления стандартных средств локальной безопасности. По умолчанию телеметрия отключена; включите её явно в конфигурации.

Обзор

• Codex по умолчанию отключает экспорт OTel, чтобы локальные запуски оставались автономными.
• При включении Codex создаёт структурированные события журналов об обсуждениях, запросах API, потоковой активности SSE/WebSocket, пользовательских запросах (по умолчанию скрытых), решениях о подтверждении инструментов и результатах их работы.
• Codex помечает экспортируемые события значением service.name (инициатор), версией CLI и меткой среды, чтобы разделять трафик dev/staging/prod.

Включение OTel (добровольное)

Добавьте блок [otel] в конфигурацию Codex (обычно ~/.codex/config.toml), выбрав экспортёр и указав, следует ли записывать текст подсказок.

[otel]
environment = "staging"   # dev | staging | prod
exporter = "none"          # none | otlp-http | otlp-grpc
log_user_prompt = false     # redact prompt text unless policy allows

• exporter = "none" оставляет инструментарий активным, но никуда не отправляет данные.
• Чтобы отправлять события собственному сборщику, выберите один из вариантов:

[otel]
exporter = { otlp-http = {
  endpoint = "https://otel.example.com/v1/logs",
  protocol = "binary",
  headers = { "x-otlp-api-key" = "${OTLP_TOKEN}" }
}}

[otel]
exporter = { otlp-grpc = {
  endpoint = "https://otel.example.com:4317",
  headers = { "x-otlp-meta" = "abc123" }
}}

Codex объединяет события в пакеты и отправляет их при завершении работы. Codex экспортирует только телеметрию, созданную его модулем OTel.

Категории событий

Примеры типов событий:

• codex.conversation_starts (модель, параметры рассуждений, политика песочницы/подтверждений)
• codex.api_request (попытка, статус/успешность, продолжительность и сведения об ошибке)
• codex.sse_event (тип потокового события, успех/сбой, продолжительность и количество токенов для response.completed)
• codex.websocket_request и codex.websocket_event (продолжительность запроса, а также тип/успешность/ошибка каждого сообщения)
• codex.user_prompt (длина; содержимое скрыто, если его регистрация не включена явно)
• codex.tool_decision (разрешено/отклонено, источник: конфигурация или пользователь)
• codex.tool_result (продолжительность, успешность, фрагмент выходных данных)

Связанные метрики OTel (пары счётчиков и гистограмм продолжительности) включают codex.api_request, codex.sse_event, codex.websocket.request, codex.websocket.event и codex.tool.call (с соответствующими инструментами .duration_ms).

Полный каталог событий и справочник по конфигурации см. в документации по конфигурации Codex на GitHub.

Рекомендации по безопасности и конфиденциальности

• Сохраняйте log_user_prompt = false, если политика явно не разрешает хранить содержимое подсказок. Подсказки могут включать исходный код и конфиденциальные данные.
• Направляйте телеметрию только контролируемым вами сборщикам; применяйте ограничения хранения и средства управления доступом в соответствии с вашими нормативными требованиями.
• Считайте аргументы и выходные данные инструментов конфиденциальными. По возможности скрывайте их на уровне сборщика или SIEM.
• Проверьте настройки локального хранения данных (например, history.persistence / history.max_bytes), если не хотите, чтобы Codex сохранял стенограммы сеансов в CODEX_HOME. См. разделы Расширенная конфигурация и Справочник по конфигурации.
• Если CLI работает с отключённым доступом к сети, экспорт OTel не сможет подключиться к сборщику. Для экспорта разрешите сетевой доступ к конечной точке OTel в режиме workspace-write или экспортируйте данные из Codex cloud, добавив домен сборщика в утверждённый список.
• Периодически проверяйте события на предмет изменений подтверждений/песочницы и неожиданного выполнения инструментов.

OTel является необязательным средством, которое дополняет, а не заменяет описанные выше механизмы защиты песочницы и подтверждений.

Управляемая конфигурация

Администраторы организаций могут настраивать параметры безопасности Codex для своей рабочей области в разделе Управляемая конфигурация. Инструкции по настройке и сведения о политиках приведены на этой странице.