Auto-review в Codex: как ускорить согласования и не расширить доступ

В длинной задаче Codex может часто останавливаться на approvals. Нужно выйти за sandbox, открыть новый домен, использовать tool с побочным эффектом, записать файл не там, куда разрешено. Каждый раз человек видит запрос и решает: можно или нельзя.

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

Auto-review нужен как более тонкий вариант. Не снять границы, а передать часть проверок отдельному reviewer-agent. Главный Codex продолжает работать в тех же рамках, но некоторые запросы на пересечение границы сначала смотрит другой агент.

Почему Auto-review не равно полный автопилот

Главная ошибка — думать, что Auto-review делает Codex свободнее. Нет. Он не должен открывать новые права сам по себе.

Если раньше агент не мог выйти в сеть, Auto-review не включает ему интернет. Если sandbox не позволял писать в соседний каталог, Auto-review не делает этот каталог разрешённым. Если protected paths закрыты, они не становятся открытыми.

Auto-review меняет не границу, а reviewer. Вместо того чтобы каждый eligible approval приходил человеку, Codex может отправить его на отдельную проверку. Reviewer смотрит конкретный запрос и решает: действие безопасно в данном контексте или нужно отказать.

Это похоже не на “включить автопилот”, а на “поставить дежурного у двери”. Дверь остаётся там же.

Что документация говорит об Auto-review

В официальной документации OpenAI Codex Auto-review описан как замена ручного approval на отдельного reviewer-agent у sandbox boundary. Main agent продолжает работать внутри того же sandbox, с той же approval policy и теми же лимитами файловой системы и сети.

Auto-review работает только там, где approvals интерактивны: например, при approvalpolicy = "on-request" или granular policy, которая всё ещё выводит нужную категорию запроса. Если стоит approvalpolicy = "never", то review просто нечего проверять.

Документация перечисляет типы ситуаций, где Auto-review может включиться: escalated shell-команды, blocked network requests, правки файлов вне allowed writable roots, некоторые MCP или app tool calls, Browser Use доступ к новому сайту или домену.

Обычные действия, которые уже разрешены текущим sandbox mode и policy, Auto-review не трогает. Они продолжают выполняться без дополнительной проверки.

Ещё важная часть: если reviewer отказывает, это не просто техническая ошибка. Main agent получает сигнал искать materially safer path или остановиться и спросить человека. Обходить отказ нельзя.

Когда его стоит включать

Auto-review уместен, когда работа длинная, approvals повторяются, а человек уже понимает общий риск-контур.

Например, Codex часто запускает однотипные тесты, просит доступ к заранее понятному инструменту, работает с соседним scratch-каталогом или периодически открывает известные домены. Если каждый запрос одинаково ожидаемый, человек быстро начинает нажимать “да” механически. Это плохой режим: approvals есть, но внимания уже нет.

Auto-review помогает сохранить проверку, не превращая человека в кнопку.

Но если задача новая, риск непонятен или агент просит широкий доступ, Auto-review не должен быть первым решением. Сначала нужно настроить границу: sandbox, writable roots, network rules, prefix rules, список запрещённых действий. И только потом решать, какие approval-запросы можно отдавать reviewer-agent.

Что дать Codex на вход

Чтобы настроить Auto-review как рабочий процесс, Codex нужно дать не только желание “меньше спрашивать”.

Первое — текущий режим. Какой sandbox используется, какая approval policy включена, есть ли network access, есть ли writable roots.

Второе — повторяющиеся остановки. Что именно мешает: сеть, файлы вне workspace, Browser Use, MCP tools, shell escalation, app tool approvals.

Третье — запреты. Например: не отправлять приватные данные, не искать токены, не ослаблять безопасность, не выполнять разрушительные действия, не обходить denied request.

Четвёртое — человеческие зоны. Даже с Auto-review некоторые решения должны оставаться ручными: публикация, удаление данных, изменение секретов, доступ к приватным системам, широкая сеть, действия с деньгами или клиентскими данными.

Пятое — правило отказа. Если reviewer отказал, Codex должен не спорить, а предложить безопасный путь или остановиться.

Как должен выглядеть результат настройки

Хороший результат — это не просто строка в конфиге. Это карта boundary.

Такая карта нужна владельцу проекта. Он видит не техническую магию, а распределение ответственности: где агент работает сам, где его проверяет reviewer, где нужен человек.

Как проверить границу без кода

Непрограммист может проверить Auto-review четырьмя вопросами.

Первый: Auto-review расширил доступ или только поменял reviewer? Правильный ответ — только поменял reviewer.

Второй: понятно ли, какие запросы он рассматривает? Если список звучит как “всё подряд”, граница слишком широкая.

Третий: есть ли действия, которые всегда остаются за человеком? Если нет, это уже не Auto-review, а скрытый полный автопилот.

Четвёртый: что происходит после отказа? Правильный процесс: Codex не ищет обход, а предлагает более безопасный вариант или останавливается.

Эти вопросы можно задать без чтения кода. Они проверяют не реализацию, а управляемость.

Где остаётся человеческое решение

Auto-review снижает количество ручных остановок, но не отменяет владельца.

Человек решает, стоит ли включать Auto-review вообще. Человек решает, какие категории запросов можно отдавать reviewer-agent. Человек решает, когда лучше изменить sandbox boundary, а не учить reviewer одобрять одно и то же. Человек решает, можно ли вручную переопределить отказ, если контекст действительно это оправдывает.

Главное — не лечить плохую границу Auto-review. Если агент постоянно просит лишнее, сначала нужно сузить задачу или поправить правила. Reviewer-agent не должен становиться привычкой соглашаться с неясными запросами.

Шаблон запроса

Можно попросить Codex так:

Помоги настроить Auto-review для этого проекта.

Текущий режим:
[sandbox mode, approval policy, network access, writable roots]

Повторяющиеся approval-запросы:
[какие именно запросы часто останавливают работу]

Нельзя автоматически одобрять:
- отправку приватных данных, секретов, токенов или cookie;
- широкое ослабление sandbox или network boundary;
- разрушительные действия без ручного решения;
- попытки обойти denied request.

Нужно получить:
1. карту boundary;
2. список запросов, которые можно отдавать Auto-review;
3. список запросов, которые остаются человеку;
4. правило поведения после denied;
5. рекомендацию: включать Auto-review сейчас или сначала изменить sandbox/rules.

Так Auto-review становится не “ещё одной настройкой для ускорения”, а аккуратным слоем контроля. Он уменьшает шум, но оставляет границу видимой. А значит, Codex может работать дольше и спокойнее, не превращаясь в агента без берегов.