Права доступа, песочница и согласование: регулируйте уровень свободы самостоятельно
📚 Навигация по серии: Предыдущая статья 14 · Типовые рабочие процессы интегрировала Codex в ваш привычный ритм разработки. Эта статья переходит в другое измерение — мы будем управлять не тем, «как он работает», а тем, «на что он имеет право замахнуться»: от режима, где каждый шаг требует подтверждения, до полной автоматизации. В этой статье мы подробно разберем, как крутить ручки «песочницы» и «согласования» и какое положение выбирать для различных сценариев.
Расрасскажу о глупости, которую я совершил прошлой зимой. Тогда я только освоился с настройкой Codex и, чтобы избавиться от «надоедливых всплывающих окон», прописал в ~/.codex/config.toml режим sandbox_mode как danger-full-access. В результате однажды в временном каталоге без инициализированного Git я попросил его «очистить ненужные файлы». И он действительно начал перекапывать всю мою домашнюю директорию — ведь в режиме полного доступа нет никаких границ в виде «рабочей области», сдерживающих его. Я в панике нажал Esc для прерывания процесса, и в тот момент у меня похолодела спина.
Анализируя это позже, я понял, что проблема была не в Codex, а во мне: я сделал глобальной настройкой по умолчанию опасную конфигурацию, предназначенную исключительно для изолированных контейнеров. Он не сошел с ума — это я отпустил вожжи там, где этого делать категорически не следовало.
В главе 02 мы уже подробно разобрали понятия песочницы и согласования на аналогиях с «забором детской площадки» и «пропускным пунктом с охранником». В этой статье мы не будем повторять определения, а займемся исключительно практикой: я покажу, как настраивать и выбирать режимы. Какую комбинацию выбрать, как временно изменить параметры через командную строку, как зафиксировать их в конфигурационном файле и где проходит красная черта опасного режима.
После прочтения этой статьи вы получите:
- Таблицу совместимости трех режимов песочницы (
read-only/workspace-write/danger-full-access) и трех стратегий согласования (untrusted/on-request/never) - Шаблоны для временной настройки через командную строку с помощью
--sandbox/--ask-for-approvalи для постоянной фиксации вconfig.toml - Знание о том, какой режим активируется по умолчанию при запуске Codex (в зависимости от наличия Git в папке) и почему
- Нюансы настроек по умолчанию: почему в режиме
workspace-writeсеть выключена по умолчанию, а папка.gitзащищена в режиме только для чтения - Где проходит красная линия для режима
--yolo(полный доступ без ограничений) и почему на рабочих и продакшн-машинах его использовать категорически запрещено
⚠️ Все упоминаемые далее конкретные команды, параметры конфигурации и значения по умолчанию соответствуют официальной документации Codex. Версии и названия моделей могут меняться с обновлениями — ориентируйтесь на то, что отображается у вас локально. Упоминаемые в статье профили прав доступа («permission profiles») являются функцией на стадии Beta и могут измениться, подробнее о них в разделе 05.
01 Проясним сразу: вы управляете «двумя независимыми ручками»
Давайте сразу зафиксируем важный момент: песочница и согласование — это не две ступени одной настройки, а две независимые ручки управления, каждая из которых отвечает за своё.
Мы уже приводили аналогии в главе 02, здесь добавим лишь то, как это выглядит в конфигурации — в файле config.toml это два разных ключа, а в командной сленге — два разных параметра:
| Ручка | За что отвечает | Ключ в конфиге | Параметр CLI | Сокращение |
|---|---|---|---|---|
| Режим песочницы (sandbox mode, границы ФС и сети) | Что разрешено делать | sandbox_mode | --sandbox | -s |
| Стратегия согласования (approval policy, запрашивать ли подтверждение) | Спрашивать ли вас | approval_policy | --ask-for-approval | -a |
Почему так важна эта «независимость»? Потому что новички часто заблуждаются, думая: «Раз я разрешил полный доступ, значит, всплывающих окон больше не будет?» Нет, это не так. Полный доступ (выкрученная на максимум ручка песочницы) и отключение подтверждений (выкрученная на максимум ручка согласования) — это разные вещи. Вы вполне можете настроить систему так, чтобы Codex имел доступ ко всей машине, но запрашивал подтверждение на каждый шаг. Или наоборот: разрешить только чтение, но без лишних прерываний. Именно их комбинация и определяет итоговый уровень строгости контроля.
Аналогия: передача и ограничение скорости при вождении. Песочница похожа на коробку передач: в режиме парковки P (read-only) машина не тронется с места, в режиме движения D (workspace-write) она едет по дороге, а во внедорожном режиме (danger-full-access) может преодолеть любые препятствия. Согласование похоже на звуковое предупреждение о скорости: оно может срабатывать только при превышении (on-request), пищать при любом препятствии (untrusted) или быть полностью отключено (never). Передача определяет, куда машина может доехать, а предупреждение — когда сигнализировать вам — они не заменяют друг друга.
Несколько практических сценариев, помогающих понять это разделение:
- Вы хотите, чтобы он только прочитал код и написал анализ: песочницу переводим в
read-only, режим согласования — любой. Поскольку менять файлы он всё равно не может, всплывающие окна не имеют значения. - Вы хотите разрешить ему свободно менять код внутри проекта, но запрашивать разрешение при выходе за его рамки: песочница
workspace-write+ согласованиеon-request. Это золотой стандарт для ежедневной работы. - Вы запускаете пакетные задачи в изолированном контейнере и не хотите отвлекаться: песочница
danger-full-access+ согласованиеnever. Обе ручки выкручены до упора — но только внутри контейнера, о чем мы будем напоминать постоянно.
💡 Резюме одной фразой: песочница (
--sandbox) отвечает за границы дозволенного, а согласование (--ask-for-approval) — за вопросы к вам. Это две независимые ручки и два разных ключа в конфигурации. Итоговый уровень контроля определяется их сочетанием.
На этой схеме две ручки контроля представлены в виде двумерной таблицы: по горизонтали — режим песочницы (от строгого read-only до свободного danger-full-access), по вертикали — стратегия согласования (от самого бдительного untrusted до тихого never). Каждое пересечение дает определенный уровень свободы. Синяя рамка workspace-write + on-request — золотой стандарт на каждый день, а красная рамка в правом нижнем углу danger-full-access + never (то есть --yolo) допустима только в изолированных контейнерах.
02 Три режима песочницы: границы дозволенного определяются здесь
Ручка песочницы имеет три положения. Официальные определения сформулированы очень четко, я свел их в таблицу с колонками «Изменение файлов», «Доступ к сети» и «Рекомендуемые задачи» — эту таблицу стоит запомнить в первую очередь:
| Режим песочницы | Изменение файлов? | Доступ к сети? | Подходящие задачи |
|---|---|---|---|
read-only (только чтение) | ❌ Нет (требуется согласование) | ❌ | Код-ревью, планирование, проектирование в формате «руками ничего не трогать» |
workspace-write (запись в рабочей области) | ✅ Только в пределах рабочей области | ❌ Выключен по умолчанию, нужно включать вручную | Режим по умолчанию для повседневной разработки, минимум отвлечений |
danger-full-access (полный доступ) | ✅ По всей системе | ✅ | Изолированные контейнеры и виртуальные машины. Слово «danger» добавлено не для красоты |
Разберем несколько важных деталей, о которых часто забывают:
Во-первых, в режиме workspace-write доступ к сети по умолчанию закрыт. Это может казаться нелогичным: «если он может писать файлы, то почему нельзя выйти в сеть и установить зависимости?» Тем не менее, это так. В официальной документации четко указано: по умолчанию в workspace-write сеть отключена. Чтобы включить ее, добавьте следующую секцию в config.toml:
[sandbox_workspace_write]
network_access = trueВ первый раз, когда я попросил Codex выполнить npm install в режиме workspace-write, он завис и выдал кучу сетевых ошибок. Я долго грешил на настройки прокси-сервера, пока не вспомнил: песочница по умолчанию перекрыла ему сеть. Запомните это правило, оно сэкономит вам немало времени.
Во-вторых, рабочая область — это не только «текущая папка». Официально в рабочую область также автоматически включаются системные временные каталоги (например, /tmp). Чтобы точно узнать, какие пути входят в рабочую область, введите команду /status в чате. Ожидаемый вывод выглядит примерно так:
Sandbox: workspace-write
Approval: on-request
Workspace directories:
/Users/you/myproject
/tmpСтроки Sandbox и Approval показывают текущие режимы, а в блоке Workspace directories перечислены каталоги, куда разрешена запись.
В-третьих, даже при включенном режиме workspace-write некоторые папки остаются под защитой «только для чтения». Это встроенная подушка безопасности Codex. Внутри рабочей области запрещено изменять следующие пути:
| Защищенный путь | Зачем нужна защита |
|---|---|
<рабочая_область>/.git | Для защиты истории коммитов Git от случайных неверных правок |
<рабочая_область>/.agents | Чтобы он не мог тайно переписать настройки своего агента |
<рабочая_область>/.codex | То же самое — служебный каталог настроек самого Codex |
Причем защита работает рекурсивно — всё содержимое внутри этих каталогов автоматически открывается только для чтения. Так что вам не стоит переживать, что Codex сможет стереть вашу папку .git: он по умолчанию блокирует изменения в этих служебных директориях.
В-четвертых, песочница ограничивает не только сам Codex, но и все запускаемые им дочерние команды. Мы упоминали об этом в главе 02, но здесь важно подчеркнуть практическую значимость: когда Codex вызывает git, npm или запускает тестовые скрипты, все эти процессы выполняются в той же песочнице. Вы застрахованы от ситуации, когда сам агент заблокирован, но его дочерняя команда смогла выйти за пределы рабочей области и изменить системные файлы.
💡 Резюме одной фразой: из трех режимов песочницы
workspace-writeявляется повседневным стандартом. Помните: доступ к сети по умолчанию закрыт, а папки.git,.agentsи.codexзащищены от записи. Сеть включается через параметрnetwork_access, а границы рабочей области проверяются командой/status.
03 Три стратегии согласования: спрашивать ли ваше мнение
Ручка согласования также имеет три положения. Песочница очерчивает границы, а нужно ли останавливаться перед их пересечением — решает стратегия согласования:
| Стратегия | Поведение Codex | Суть простыми словами |
|---|---|---|
untrusted | Выполняет автоматически только «заведомо безопасные» операции чтения, в остальных случаях запрашивает разрешение | Блокирует любые неизвестные действия, максимальная предосторожность |
on-request | Работает самостоятельно внутри песочницы, останавливается и спрашивает только при выходе за её рамки | Сбалансированный повседневный режим |
never | Никогда не запрашивает подтверждений, работает тихо | Используется для автоматизации; права по-прежнему ограничены песочницей, максимальный эффект дает в сочетании с полным доступом |
Здесь стоит упомянуть один официальный нюанс: режим untrusted не означает полную блокировку записи («только чтение»). Он по-прежнему автоматически выполняет безопасные операции чтения. Но любые действия, способные изменить состояние системы или вызвать внешние процессы (например, деструктивные команды Git или перезапись файлов конфигурации), потребуют вашего одобрения. На практике untrusted ощущается как «читать можно свободно, но при малейшем подозрении на действие — подтверждай». Он заметно строже и осторожнее, чем on-request.
Обратите внимание на продвинутый нюанс: режим never совместим с любым уровнем песочницы. Многие ошибочно полагают, что never означает полную свободу действий. Это не так. Официальная документация подтверждает, что параметр --ask-for-approval never можно использовать с любым режимом --sandbox. Вы можете настроить связку read-only + never, что означает: «разрешено только чтение, и при этом не нужно отвлекать меня вопросами». Это классический вариант для запуска статического анализа в CI. «Не спрашивать» и «дать полную свободу» — абсолютно разные вещи, и в этом еще раз проявляется независимость двух ручек управления.
Что касается роли проверяющего, то по умолчанию запросы приходят вам лично (approvals_reviewer = "user"). Также доступна опция автоматической проверки auto_review, когда промежуточный агент-цензор оценивает запросы до показа пользователю. Это продвинутая развивающаяся функция. В главе 16 · Безопасность и границы рисков мы подробно разберем ее логику и возможные угрозы, а пока для повседневных задач настройки user вполне достаточно.
💡 Резюме одной фразой: стратегия
on-requestявляется стандартом на каждый день. Стратегияuntrustedболее дробная и осторожная (разрешает чтение, но блокирует действия без подтверждения). Режимneverлишь отключает вопросы, но не расширяет права; он совместим с любой песочницей (например, связкаread-only + neverидеальна для CI).
04 Как сочетать параметры: временный вызов через CLI и постоянная фиксация в config.toml
После того как мы разобрали все режимы, настроить их можно двумя путями: временно переопределить через параметры запуска в консоли или зафиксировать на постоянной основе в конфигурационном файле.
临时改：命令行参数（只管这一次）
Задайте два параметра при запуске, чтобы определить строгость контроля на эту сессию. Рекомендуемое официальное безопасное сочетание на каждый день выглядит так:
codex --sandbox workspace-write --ask-for-approval on-requestГраницы очерчены, вопросы задаются только при выходе за их пределы — безопасно и не отвлекает. Есть и краткая форма с флагами -s и -a:
codex -s read-only -a on-request "只帮我审一下这段代码，别动手"Хотите изменить настройки прямо во время работы, не выходя из сессии? Используйте команду со слэшем:
/permissionsПоявится меню выбора (Read Only / Auto / Full Access и т.д.), и изменения вступят в силу мгновенно. Мой рабочий ритм обычно таков: приступая к незнакомому проекту, я первым делом переключаю права через /permissions в режим только чтения (Read Only). Даю ему проанализировать код и предложить решения, и лишь когда суть мне ясна — возвращаю workspace-write. Эта привычка не раз спасала меня от необдуманных автоматических правок в коде, в котором я сам еще не успел разобраться.
⚠️ Меню в новых версиях может отличаться: начиная с версии codex-cli 0.142, разработчики представили профили прав доступа permission profiles (Beta, могут измениться), заменяющие старые настройки. Команда
/permissionsтеперь может выводить стратегии согласования вродеAsk for approval/Approval for me/Full access, без явного пунктаRead Only. В таких случаях для запуска в режиме только чтения используйте параметр командной строкиcodex --sandbox read-onlyили укажитеsandbox_mode = "read-only"в файле~/.codex/config.toml(старый режим поддерживается для обратной совместимости). Последующие упоминания переключения в Read Only через меню/permissionsследует понимать с учетом этой оговорки.
Схема ниже показан двухэтапный процесс принятия решений «проверка песочницы → проверка согласования»:
Схема наглядно иллюстрирует логику: перед каждым действием Codex сначала проверяет «находится ли оно внутри песочницы» (это определяет песочница). Если действие выходит за рамки, вступает в силу второй уровень контроля: «нужно ли спросить согласия» (это определяет согласование). Эти два рубежа защиты работают последовательно.
写死：config.toml 当默认（每次启动都生效）
每次都敲参数太烦，把常用组合写进配置文件一劳永逸。文件在 ~/.codex/config.toml，加这两行：
approval_policy = "on-request"
sandbox_mode = "workspace-write"想要「最谨慎」的兜底配法？官方给的「永远先问」组合是
approval_policy = "untrusted"配sandbox_mode = "read-only"，等于每次启动都从最严开始，需要放权时再手动切。生产项目、共享机器适合这么兜底。
如果你有好几套常用组合（比如「日常一套、CI 一套」），别在一个文件里反复改——官方支持配置预设档（profile），把每套存成单独文件，用 --profile 选：
# ~/.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 --profile full_auto⚠️ 这里说的 profile（配置预设档）和第 05 节要讲的 permission profile（权限配置档）是两个不同的东西，名字像但别混：前者是「把一组配置打包命名」的老办法，后者是更新的、专门描述文件系统 + 网络边界的 Beta 机制。本节这套
sandbox_mode+approval_policy是目前的主线配法，先把它吃透。
💡 一句话总结：临时改用
-s/-a或会话里/permissions，永久改写进~/.codex/config.toml的sandbox_mode+approval_policy；多套常用组合用--profile切，这套是当前主线，先掌握它。
05 Тонкая настройка: правила rules для команд и профили permission profiles для границ (Beta)
Параметры «режим песочницы + стратегия согласования» из раздела 04 — это крупные мазки для задания общей политики безопасности. Если же вам нужно точечно указать: «вот эту команду разрешить всегда, а эту — полностью запретить», у Codex есть инструменты более тонкой настройки. Начинающие могут пропустить этот раздел и вернуться к нему по мере необходимости.
rules：给单条命令定规矩（实验性）
⚠️ 实验性，可能变化。 rules 是官方标注的实验功能。
Механизм точечного контроля за отдельными командами в Codex называется rules (правила). Обратите внимание, что для принятия решений используются термины allow (разрешить), prompt (запросить подтверждение) и forbidden (запретить), а не ask / approve / deny, которые встречаются в неофициальных руководствах. Не путайте синтаксис.
规则写在 ~/.codex/rules/ 下的 .rules 文件里，语法像 Python（实际是 Starlark）。一条规则长这样：
prefix_rule(
pattern = ["gh", "pr", "view"],
decision = "prompt",
justification = "查看 PR 允许，但要我点头",
)Параметр decision принимает одно из трех значений, логика приоритетов которых жестко прописана — применяется самое строгое правило (forbidden > prompt > allow):
| decision | Результат |
|---|---|
allow | Выполнять сразу при выходе из песочницы, без вопросов |
prompt | 所有匹配都先问你 |
forbidden | 直接拦死，不问也不跑 |
Встроенная защита работает очень надежно: если в консоли передается цепочка команд в одну строку вроде git add . && rm -rf /, Codex в целях безопасности разобьет ее на отдельные команды и проверит каждую по очереди. Даже если вы разрешили (allow) команду git add, выполнение rm -rf / будет перехвачено и заблокировано отдельно — протащить опасную команду «прицепом» не удастся. Для тестирования измененных правил используйте команду codex execpolicy check [команда], чтобы заранее увидеть вердикт, не рискуя реальной системой.
permission profiles：把文件系统 + 网络边界打包成一个 profile（Beta）
⚠️ Beta，可能变化，且和老的沙箱设置「不能混用」。 这是官方反复强调的——如果你的任何配置文件里出现了
sandbox_mode、或你传了--sandbox，Codex 就还是走老的沙箱设置，不会用 permission profiles。两套二选一，别同时配。
Если вы считаете, что режим workspace-write слишком размыт, и хотите точечно настроить права («запись разрешена только в эту папку, файл .env закрыт полностью, доступ разрешен только к следующим доменам»), для этого используются профили прав доступа (permission profiles). Они объединяют правила файловой системы и сетевые правила в именованный профиль (profile), а параметр default_permissions задает профиль по умолчанию.
В системе есть три встроенных профиля, их названия говорят сами за себя (обратите внимание на двоеточие в начале имени):
| Встроенный профиль | Назначение |
|---|---|
:read-only | Локальные команды выполняются только в режиме чтения |
:workspace | Разрешена запись в корень рабочей области и системную временную папку |
:danger-full-access | Полное снятие ограничений локальной песочницы, использовать только при крайней необходимости |
自定义一个长这样（文件系统精确到「工作区可写、但所有 .env 拦死」）：
default_permissions = "project-edit"
[permissions.project-edit]
extends = ":workspace"
[permissions.project-edit.filesystem.":workspace_roots"]
"." = "write"
"**/*.env" = "deny"
[permissions.project-edit.network]
enabled = true
[permissions.project-edit.network.domains]
"api.openai.com" = "allow"Для файловой системы предусмотрено три типа прав: read (чтение), write (запись) и deny (запрет). Логика приоритетов аналогична правилам rules — правило deny имеет наивысший приоритет (deny > write > read), при этом более точный путь переопределяет общий. Преимущество такой схемы очевидно: вы можете разрешить запись во всю рабочую область, но сделать жесткое исключение для файлов .env, сочетая общий и детальный контроль в одной конфигурации. Сеть настраивается по принципу «белого списка»: если домен явно не разрешен через allow, доступ к нему закрыт. Правило deny всегда имеет приоритет над allow.
Мой совет прост: начинающим не стоит сразу браться за профили, настройте стабильную работу по схеме из раздела 04. Когда возникнет реальная необходимость жестко заблокировать конкретный конфиг или ограничить список доменов — тогда и придет время для профилей. И не забудьте стереть параметр sandbox_mode из настроек перед переходом на профили, чтобы избежать конфликтов.
💡 Резюме одной фразой: правила rules позволяют точечно контролировать вызовы по префиксам команд (
allow/prompt/forbidden, побеждает строгое правило). Профили permission profiles (Beta) задают точные границы по путям файлов и доменам (denyимеет высший приоритет). Оба инструмента предназначены для продвинутых пользователей. В обычных условиях используйте стандартную схему.
06 Настройки по умолчанию при запуске + красная черта опасного режима
Разобравшись с механизмами, перейдем к выбору конкретного режима. Полезно знать: при запуске Codex самостоятельно активирует наиболее подходящий режим по умолчанию, анализируя наличие Git в текущей папке.
Codex 默认给你哪一档
Логика системы очень разумна: при запуске проверяется наличие системы контроля версий (Git) в каталоге, и на основе этого предлагается соответствующий режим:
| Папка, где запущен Codex | Режим по умолчанию |
|---|---|
| Под управлением Git (version-controlled) | Режим Auto (workspace-write + on-request) |
| Без Git (non-version-controlled) | Режим read-only (только чтение) |
Это логичное решение: если проект находится под контролем Git, любые неверные правки можно увидеть через git diff и легко откатить, поэтому запись в рабочую область разрешена по умолчанию. Если папка не отслеживается в Git, изменения нельзя вернуть назад, поэтому для безопасности включается только чтение. Возвращаясь к моей зимней истории — я как раз запустил полный доступ во временной папке без Git, собственноручно отключив оба рубежа защиты. Стоит ли удивляться результату?
Еще один нюанс: в ряде случаев Codex начинает работу в строгом режиме read-only, пока вы явно не подтвердите «доверие» к текущему каталогу (через стартовый запрос или команду /permissions). Если агент поначалу отказывается писать файлы и только читает их — не пугайтесь, он просто ждет подтверждения доверия к каталогу.
Отдельно стоит упомянуть настройку поиска в интернете: поиск (web search) по умолчанию работает в режиме кэширования (cached), а не живых запросов. Система использует готовую базу проиндексированных результатов, что снижает риски атак класса «внедрение промпта через веб-страницы» (prompt injection). Интересный нюанс: если вы включите полный доступ (режим --yolo), поиск автоматически переключится в живой режим (live). Для принудительного включения живого поиска используйте флаг --search, а для полного отключения прописась web_search = "disabled". Подробнее об аспектах безопасности мы поговорим в главе 16 · Безопасность и границы рисков.
--yolo：完全放开的红线
И наконец, поговорим о той самой красной черте — режиме полной свободы, из-за которого я пострадал в прошлом году. В Codex этот режим можно включить двумя эквивалентными путями:
- 配置层面：
sandbox_mode = "danger-full-access"配approval_policy = "never" - 命令行一把梭：
--dangerously-bypass-approvals-and-sandbox（简短别名--yolo，you only live once）
Название --yolo (you only live once — живем один раз) недвусмысленно намекает на опасность. Этот флаг одновременно отключает песочницу и согласование, позволяя Codex выполнять любые действия в системе без единого вопроса. Сверяйтесь с таблицей перед его включением:
| Окружение | Стоит ли включать --yolo / полный доступ? |
|---|---|
| Изолированный контейнер / VM / dev container | ✅ Можно. Любые разрушения затронут только временную среду |
| Разовые задачи в CI (внутри контейнера) | ✅ Можно, если сама среда выполнения полностью изолирована |
| Собственная рабочая машина | ❌ Нет. Лучше потратить секунду на подтверждение, чем рисковать системой |
| Машина с важными данными или продакшн-кодом компании | ❌ Категорически нет. Это пороховая бочка |
Официальная позиция разработчиков однозначна: полный доступ помечен как (not recommended) (не рекомендуется). Если ваша операционная система не поддерживает изоляцию песочницы Linux или компания использует контейнеры для разработки, правильным подходом будет настроить изоляцию во внешнем Docker / dev container и уже внутри него запускать --yolo — пусть контейнер служит надежной внешней границей безопасности, не стоит снимать ограничения на реальном хосте. В репозитории есть готовый пример безопасного devcontainer (с контролем исходящего трафика на уровне фаервола), который можно взять за основу.
Но важно передать вам еще одно официальное предупреждение: даже полный доступ внутри devcontainer не обеспечивает абсолютной безопасности — вредоносный проект может украсть любые данные, доступные внутри контейнера (включая авторизационные токены Codex). Поэтому даже в контейнере запускайте полный доступ только для проверенных репозиториев кода и контролируйте действия агента так же тщательно, как и в любой другой среде с повышенными привилегиями.
Мой личный вывод, написанный горьким опытом, прост: полный доступ допустим только в изолированных средах, которые не жалко стереть или потерять. На рабочих и домашних компьютерах его использовать нельзя. Надоедливые окна — не оправдание. Лучше лишний раз кликнуть мышкой, чем потом восстанавливать систему.
💡 Резюме одной фразой: Codex автоматически выбирает режим по умолчанию в зависимости от наличия Git (есть Git → Auto, нет Git → только чтение), не отключайте этот контроль. Поиск по умолчанию кэшируется для защиты от инъекций промптов. Режим
--yolo(полный доступ) допустим только в изолированных контейнерах, на рабочих машинах его использовать запрещено.
07 Практика: переключаем три уровня доступа за 5 минут
Теория без практики быстро забывается. Давайте на примере пустой папки посмотрим, как Codex реагирует на один и тот же запрос в разных режимах — останавливается для вопроса или выполняет команду сразу. Реальные проекты для этого не понадобятся.
第一步：建个空目录，进去启动 Codex。
Mac / Linux（Windows 用 PowerShell，把 mkdir -p 换成 mkdir）：
mkdir -p ~/perm-demo && cd ~/perm-demo
codex注意：这个目录没初始化 Git。按第 06 节讲的默认逻辑，Codex 很可能一进来就给你
read-only起步——正好，省得我们手动切。
第二步：确认当前档位。
进会话先看一眼自己现在在哪档：
/statusОжидаемый результат: появится текущий статус песочницы и согласования, а также пути рабочей области. Зафиксируем этот вывод как отправную точку.
第三步：在只读档下，让它干一件「要写文件」的事。
确保当前是只读（不是的话敲 /permissions 切到 Read Only），然后丢给它：
帮我新建一个文件 hello.txt，里面写一行 "hello codex"。Ожидаемый результат: Codex не будет молча создавать файл, а остановится для запроса подтверждения, так как запись выходит за рамки read-only. Сообщение будет следующего вида:
我需要创建文件 hello.txt，这超出了当前只读模式的权限，是否允许？Этот шаг наглядно показывает совместную работу песочницы и согласования: песочница определила выход за границы, а согласование вывело запрос пользователю.
第四步：切到工作区可写，对比放行的顺滑。
/permissionsВ появившемся меню переключитесь в режим Auto / Workspace Write и повторите команду создания файла hello.txt. Ожидаемый результат: в этот раз файл будет создан сразу и без лишних вопросов, поскольку запись в рабочей области разрешена песочницей.
已创建 hello.txt第五步（可选）：感受网络默认是关的。
Находясь в режиме записи в рабочей области, попросите его выполнить сетевой запрос:
帮我用 curl 访问一下 https://example.com，把返回内容贴出来。Ожидаемый результат: поскольку сеть в режиме workspace-write по умолчанию отключена (как мы разбирали в разделе 02), Codex либо выдаст запрос на подтверждение доступа, либо сообщит об ошибке сети. Это подтверждает правило «запись файлов ≠ доступ к сети». Для включения сети потребуется отредактировать параметр network_access в config.toml, но для данного упражнения это делать необязательно.
Пройдя эти шаги, вы на практике убедились в работе ограничений только для чтения, записи в рабочей области и сетевой защиты. Все последующие настройки безопасности строятся на этих принципах.
💡 Резюме одной фразой: создайте пустую папку, проверьте статус через
/status, попробуйте записать файл в режиме Read Only и посмотрите на блокировку, переключитесь в режим авто-записи и убедитесь в успешном выполнении, а затем попробуйте открыть сеть. Практическое переключение режимов заменяет чтение десятка инструкций.
08 Итоги
В этой статье мы разобрали механизмы управления правами доступа в Codex — уровень его свободы полностью определяется сочетанием ручек песочницы и согласования.
Коротко повторим ключевые выводы:
| Задача | Инструмент | Главный нюанс |
|---|---|---|
| Настройка границ дозволенного | Песочница --sandbox | Три режима: read-only / workspace-write / danger-full-access |
| Запрос подтверждений | Согласование --ask-for-approval | Три стратегии: untrusted / on-request / never (независимо от песочницы) |
| Временное переопределение | Параметры запуска / /permissions | Возможность смены режима прямо внутри сессии |
| Постоянная фиксация | Файл config.toml | Ключи sandbox_mode + approval_policy; выбор профилей через --profile |
| Точечный контроль команд и путей | Правила rules / permission profiles | Для продвинутых пользователей. Не смешивайте профили со старыми настройками |
| Отключение всех ограничений | Флаг --yolo | Использовать только в изолированных контейнерах, на хост-машинах запрещено |
Теперь вы умеете: подбирать оптимальные связки из трех режимов песочницы и трех стратегий согласования под свои задачи, временно изменять их через консоль и фиксировать по умолчанию в config.toml. Вы знаете, как система сама предлагает уровень защиты в зависимости от наличия Git в папке, почему сеть закрыта по умолчанию в workspace-write, а каталог .git защищен от записи, и почему режим --yolo нельзя запускать вне контейнеров. Умение гибко настраивать права дает уверенность при работе с Codex и страхует от фатальных ошибок.
В следующей статье — 16 · Безопасность и границы рисков. Мы разобрали технические настройки прав, но остается более важный вопрос: можно ли в принципе доверять AI работу со своим кодом и системой? Как работают атаки класса внедрения промптов (prompt injection)? Как защитить конфиденциальные данные? Как устроена безопасность живого веб-поиска и авто-цензуры? Теперь, когда вожжи у вас в руках, поговорим о том, когда их стоит натягивать, а когда можно отпустить.