Какие команды Codex можно запускать без спроса: правила allow, prompt и forbidden
Главный страх при работе с Codex звучит просто: "а вдруг он запустит не то". Не обязательно что-то драматическое. Иногда достаточно удалить не тот файл, отправить не тот запрос, перезаписать рабочий артефакт или выполнить команду, которая в тестовой среде нормальна, а в production уже опасна.
Официальная документация OpenAI по Rules показывает, что поведение Codex можно описывать не только общими просьбами, но и правилами для команд. У правила есть шаблон, решение и объяснение. Решения тоже понятные: разрешить, спросить или запретить. Для владельца проекта это можно перевести на язык светофора: зеленая зона, желтая зона и красная зона.
Важная мысль: правила нужны не для того, чтобы "дать Codex больше свободы". Они нужны, чтобы свобода была предсказуемой.
Разрешения должны быть не настроением, а картой
Без правил команда каждый раз превращается в маленький спор. Можно ли запустить тесты? Можно ли собрать проект? Можно ли поставить пакет? Можно ли отправить письмо? Можно ли удалить временную папку? Если каждый раз решать с нуля, работа тормозит. Если разрешить все, риск растет.
Правила дают середину. Повторяемые безопасные действия уходят в автоматический режим. Сомнительные действия требуют подтверждения. Опасные действия блокируются заранее.
| Зона | Что означает | Пример для проекта |
|---|---|---|
| allow | Codex может выполнить сам | чтение файлов, запуск тестов, сборка preview, проверка статуса очереди |
| prompt | Codex должен спросить | публикация, отправка письма, изменение внешней системы, установка зависимости |
| forbidden | Codex не должен выполнять | удаление production-данных, раскрытие секретов, обход очереди публикаций |
Такой светофор особенно полезен в проектах, где Codex работает не один раз, а регулярно: пишет статьи, проверяет сайт, обновляет документы, читает задачи, готовит публикации.
Что дать Codex как вход
Чтобы написать правила, не нужно начинать с синтаксиса. Начните со списка обычных действий проекта.
Например:
В этом проекте Codex может сам читать файлы, искать по репозиторию, запускать локальный review gate и собирать отчет. Он должен спрашивать перед публикацией в Ghost, отправкой писем, изменением расписания и запуском команд, которые пишут во внешние сервисы. Ему запрещено печатать токены, direct-send в соцсети, удалять production-данные и обходить ArticleFactory.
Из такого текста уже можно делать технические правила. Но даже до технического слоя он полезен: владелец проекта видит, какие действия считаются нормальной рутиной, а какие остаются человеческим решением.
Зеленая зона не должна быть широкой
Самая частая ошибка - разрешить целую группу команд ради удобства. Например, "можно запускать все python-скрипты". В маленьком проекте это звучит безобидно. В живом контуре один скрипт может читать статус, второй публиковать, третий удалять, четвертый отправлять данные наружу.
Зеленая зона должна быть скучной:
- Команда не меняет внешний мир.
- Команда не отправляет сообщения.
- Команда не публикует.
- Команда не удаляет важные данные.
- Результат команды легко проверить.
Запуск локального теста обычно подходит. Проверка буфера очереди подходит. Чтение документа подходит. А вот "починить и сразу отправить" уже не зеленая зона, даже если это технически одна команда.
Желтая зона нужна не потому, что Codex слабый
Prompt-зона - это не недоверие к агенту. Это признание, что у действия есть бизнес-последствия. Codex может правильно подготовить письмо, но человек решает, отправлять ли его. Codex может подготовить публикацию, но человек или gate решает, выпускать ли ее. Codex может предложить изменение правил, но не должен сам расширять себе полномочия.
Желтая зона особенно важна для действий, где ошибка видна не сразу. Например, изменение расписания публикаций может выглядеть технически успешным, но сломать редакционный ритм. Установка новой зависимости может пройти без ошибок, но поменять поведение сборки. Публикация может быть корректной по формату, но преждевременной по смыслу.
Красная зона должна быть записана явно
Запреты лучше писать не в стиле "будь аккуратен", а как конкретные границы.
Плохая формулировка:
Не делай опасных действий.
Рабочая формулировка:
Не печатай секреты. Не запускай direct-send Telegram/VK. Не создавай native VK delayed posts в обход factory. Не удаляй production-данные. Не меняй права доступа без явного задания. Не публикуй статью без review gate, live audit и verified visual media.
Такой список кажется жестким, зато его можно проверить. Codex понимает, что именно запрещено. Человек понимает, где автоматизация остановится.
Как проверить правила без программиста
Не-программист может не читать конфигурационный файл. Но он может проверить карту команд:
| Вопрос | Хороший ответ |
|---|---|
| Какие команды Codex запускает сам? | Только безопасные, повторяемые и проверяемые |
| Какие команды требуют вопроса? | Все, что меняет внешний мир или имеет бизнес-последствия |
| Что запрещено всегда? | Секреты, публикации в обход gate, удаление важных данных, обход очереди |
| Где это записано? | В проектных правилах, policy, AGENTS.md или конфигурации Codex |
| Как узнаем, что правило сработало? | Codex вернул запрос подтверждения или отказался выполнять действие |
Если на эти вопросы нет ответа, проблема не в Codex. Проблема в том, что проект не описал свои границы.
Где остаётся человеческое решение
Codex может предложить набор правил, сгруппировать команды, объяснить риски и подготовить конфигурацию. Он может показать, какие действия повторяются чаще всего и где автоматизация сэкономит время. Но человек решает, какой риск приемлем.
В маленьком личном проекте можно разрешить больше. В клиентском проекте надо спрашивать чаще. В публикационном контуре direct-send может быть запрещен полностью, потому что существует отдельная очередь и audit. В финансовом или юридическом контуре красная зона будет еще жестче.
Rules в Codex - это не техническая игрушка. Это способ превратить агентскую работу в управляемый процесс: вот что можно делать сразу, вот где нужно спросить, вот что нельзя никогда. Чем яснее эта карта, тем меньше приходится останавливать работу вручную и тем меньше шансов, что скорость превратится в последствия.