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

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

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

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

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

Средства безопасности 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 всегда требуют подтверждения, если у инструмента имеется аннотация о разрушительном характере действия, даже когда наряду с ней указаны другие свойства (например, признак «только для чтения»).

Доступ к сети

Сведения о включении полного доступа к интернету или списка разрешённых доменов для 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 включена: сеть остаётся включённой, а исходящий трафик ограничивается настроенной сетевой политикой.

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

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

Правила доменов в первую очередь основаны на списке разрешений:

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

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

По умолчанию allow_local_binding = false блокирует адреса обратной петли, локальные адреса канала и частные адреса назначения:

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

Защита от перепривязки DNS

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

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

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

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

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

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

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

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

Вы также можете управлять инструментом веб-поиска, не предоставляя запущенным командам полный доступ к сети. По умолчанию 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 как устаревший путь совместимости и выводит предупреждение.

При использовании --ask-for-approval untrusted Codex автоматически выполняет только заведомо безопасные операции чтения. Команды, которые могут изменять состояние или запускать внешние цепочки выполнения (например, разрушительные операции Git либо флаги вывода или переопределения конфигурации Git), требуют подтверждения.

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

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

# Always ask for approval mode
approval_policy = "untrusted"
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 и обновления 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 и метку среды для разделения трафика разработки, промежуточной и рабочей сред.

Включение 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 не сможет подключиться к вашему сборщику. Для экспорта разрешите сетевой доступ в режиме workspace-write к конечной точке OTel либо выполняйте экспорт из облачной среды Codex, добавив домен сборщика в список разрешённых.
• Периодически проверяйте события на предмет изменений настроек одобрения и песочницы, а также неожиданного выполнения инструментов.

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

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

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