Rules: какие команды разрешать без вопросов

Песочница отвечает на вопрос «куда агенту можно», а правила (rules) — «какие команды можно запускать за её пределами и нужно ли при этом спрашивать». Это способ убрать однотипные запросы одобрения, не расширяя песочницу целиком: разрешить git commit и glab mr view, но всегда спрашивать про docker compose down и никогда не выполнять git push --force. Механизм экспериментальный, синтаксис может меняться.

Где лежат правила

Правила — файлы с расширением .rules в каталоге rules/ рядом с любым активным слоем конфигурации:

• ~/.codex/rules/default.rules — личные правила;
• <репозиторий>/.codex/rules/*.rules — проектные, загружаются только для доверенного проекта;
• системные и командные расположения, а также requirements.toml, через который администратор может навязать запрещающие правила.

Codex читает правила при старте, поэтому после правки перезапустите сессию.

Когда в TUI вы отвечаете на запрос одобрения вариантом «разрешать всегда», Codex дописывает правило в ~/.codex/rules/default.rules. А функция Smart approvals, включённая по умолчанию, может сама предложить префикс для правила прямо в запросе. Читайте предложенный префикс внимательно: ["php"] вместо ["php", "artisan", "test"] разрешит любой PHP-скрипт.

Синтаксис prefix_rule

Файлы пишутся на Starlark — это подмножество Python, которое исполняется без побочных эффектов. Основная конструкция — prefix_rule:

prefix_rule(
    pattern = ["glab", "mr", ["view", "list", "diff"]],
    decision = "allow",
    justification = "Чтение merge request в GitLab безопасно",
    match = [
        "glab mr view 128",
        "glab mr diff 128 --color never",
    ],
    not_match = [
        "glab mr merge 128",
    ],
)

Поля:

• pattern — обязательный непустой список: префикс команды по аргументам. Элемент — строка или список строк, то есть «любой из вариантов на этой позиции».
• decision — allow (по умолчанию), prompt или forbidden. allow выполняет команду вне песочницы без вопросов, prompt спрашивает при каждом вызове, forbidden блокирует без вопросов.
• justification — понятная человеку причина; Codex может показать её в запросе или в отказе. Для forbidden полезно написать, что делать вместо.
• match и not_match — встроенные мини-тесты. Codex проверяет их при загрузке, и ошибка в шаблоне всплывает сразу, а не в середине задачи.

Если подошло несколько правил, побеждает самое строгое: forbidden сильнее prompt, prompt сильнее allow.

Набор правил для веб-проекта

# Коммиты: запись в .git — выход за песочницу, но действие обратимое
prefix_rule(
    pattern = ["git", "commit"],
    justification = "Коммиты в рабочей ветке разрешены",
    match = ["git commit -m 'fix: валидация формы'"],
)

# Зависимости тянут код из сети — каждый раз спрашиваем
prefix_rule(
    pattern = [["composer", "npm"], ["require", "install"]],
    decision = "prompt",
    justification = "Новые зависимости согласуем с человеком",
    match = ["composer require guzzlehttp/guzzle", "npm install lodash"],
)

# Остановка окружения снесёт данные локального стенда
prefix_rule(
    pattern = ["docker", "compose", "down"],
    decision = "prompt",
    justification = "Может удалить тома с локальной базой",
)

# Переписывать историю на сервере агенту нельзя
prefix_rule(
    pattern = ["git", "push", ["--force", "-f", "--force-with-lease"]],
    decision = "forbidden",
    justification = "Не переписывай историю. Сделай новый коммит и обычный git push",
    match = ["git push --force", "git push -f origin main"],
    not_match = ["git push origin task-123"],
)

Обратите внимание на ограничение последнего правила. Сопоставление идёт по префиксу: git push --force и git push -f origin main попадут под запрет, а git push origin main --force — нет, потому что флаг стоит не на третьей позиции. Правила — удобный фильтр, но не стена. Настоящую защиту ветки main дают защищённые ветки в GitLab, а не только конфигурация агента.

Цепочки команд в одной строке

Агенты любят запускать несколько команд через bash -lc "...". Codex обрабатывает такие обёртки (bash, zsh, sh с -c или -lc) особо. Если скрипт — простая цепочка обычных слов, соединённых &&, ||, ; или |, Codex разбирает его на отдельные команды и проверяет каждую. Так git add . && rm -rf / не пройдёт под прикрытием разрешённого git add: вторая команда проверяется отдельно, и побеждает самый строгий результат.

Если в скрипте есть перенаправления, подстановки $(...), переменные, шаблоны * или управляющие конструкции, Codex не пытается его разбирать и сверяет правила со всей строкой ["bash", "-lc", "<скрипт>"]. Такая команда обычно не совпадёт ни с одним разрешающим правилом и уйдёт на одобрение — это консервативное и правильное поведение.

Проверка правил

Перед тем как класть файл в репозиторий, прогоните его через codex execpolicy check:

codex execpolicy check --pretty \
  --rules .codex/rules/project.rules \
  -- git push -f origin main

Команда печатает JSON с итоговым решением, совпавшими правилами и их justification. Флаг --rules можно повторять, чтобы проверить личные и проектные правила вместе. Для одного запуска codex exec правила можно отключить флагом --ignore-rules — например, чтобы понять, не они ли мешают скрипту.

Связь с одобрениями

Правила работают внутри политики одобрений. Несколько сочетаний, которые стоит понимать:

• approval_policy = "on-request" — команды внутри песочницы идут без вопросов, а для выхода за неё срабатывают правила: allow пропускает, prompt спрашивает, forbidden отказывает.
• prompt заставляет спрашивать и про команду, которая формально помещается в песочницу. Этим пользуются, когда действие безопасно технически, но требует решения человека.
• Строгий режим «спрашивать почти всё» теперь включается не устаревшим approval_policy = "untrusted", а доверием к проекту: [projects."/path"] trust_level = "untrusted" в личном конфиге. Тогда команды требуют одобрения, если их не разрешает правило, — но и проектные .codex/ при этом не загружаются, так что правила должны лежать в личном слое.
• Гранулярная политика approval_policy = { granular = { ... } } позволяет оставить интерактивными одни категории запросов и автоматически отклонять другие. Категория rules = true/false отвечает как раз за запросы, вызванные правилами prompt.

approval_policy = { granular = { sandbox_approval = true, rules = true, mcp_elicitations = true, request_permissions = false, skill_approval = false } }

Auto-review: когда отвечает не человек

Иногда правилами всё не опишешь, а сидеть и нажимать «да» на каждый запрос не хочется. Для этого есть автоматическая проверка одобрений (auto-review): запросы на выход за границу рассматривает отдельный агент-ревьюер вместо вас.

codex --approve-for-me          # алиас: --not-so-yolo

approval_policy = "on-request"
approvals_reviewer = "auto_review"   # по умолчанию 2

--approve-for-me включает песочницу workspace-write с on-request и ревьюером auto-review, поэтому не сочетается с --sandbox и --yolo. В десктопе и IDE этот режим называется «Approve for me».

Что важно понимать:

• Ревьюер — это замена того, кто одобряет, а не расширение прав. Он не открывает сеть, не добавляет каталоги и не снимает защиту с .git.
• Он смотрит только запросы, которые и так требовали одобрения: эскалации из песочницы, заблокированную сеть, правки вне рабочей области, MCP-вызовы с побочными эффектами. Обычная работа внутри песочницы идёт без него.
• Политика ревьюера лежит в открытом коде Codex (policy.md) и блокирует утечку секретов, поиск учётных данных, ослабление защиты и разрушительные действия. Локально её можно заменить в [auto_review].policy — документация советует сначала скопировать политику целиком и дописывать к ней.
• Отказ — не повод искать обходной путь: агент получает указание найти заметно более безопасный вариант или спросить вас. После трёх отказов подряд или десяти из последних пятидесяти проверок в одном ходе Codex прерывает ход.
• Если ревьюер отклонил действие, которое вы считаете нормальным, /approve разрешает один повтор именно этого действия; повтор всё равно проходит через ревьюера, и тот может отклонить его снова.
• С approval_policy = "never" ревьюировать нечего, а каждая проверка — дополнительные вызовы модели, которые расходуют лимит.

Хорошая последовательность: сначала расширьте песочницу там, где это безопасно (writable_roots, список доменов), затем добавьте узкие правила для частых команд, и только остаток отдавайте auto-review. Если ревьюер одобряет одно и то же десятки раз — это кандидат в правило.