Руководство Codex

Тема

Правила команд и автоматические проверки ​

Зачем это изучать

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

Проверено: 23 июля 2026 года по официальной документации OpenAI.

Технические правила управляют разрешениями для команд, а автоматические проверки запускают ваши команды при определённых событиях Codex. Это разные механизмы: правило отвечает «разрешить ли действие», проверка — «какую дополнительную команду выполнить».

Что выбрать ​

МеханизмНазначение
Технические правилаРазрешить, переспросить или запретить точное начало команды
Автоматические проверкиПроверить или записать событие до либо после действия Codex
AGENTS.mdТекстовые правила работы в каталоге
Требования организацииОбязательные ограничения администратора

Инструкция в AGENTS.md не заменяет техническое ограничение, а hook не является полной границей безопасности.

Технические правила ​

Rules считаются экспериментальной возможностью. Пользовательские файлы обычно находятся рядом с активной конфигурацией, например ~/.codex/rules/default.rules; проектные — в доверенном каталоге .codex/rules/.

python
prefix_rule(
    pattern = ["gh", "pr", "view"],
    decision = "prompt",
    justification = "Чтение pull request требует явного сетевого доступа",
    match = ["gh pr view 42"],
    not_match = ["gh issue view 42"],
)

Правило сопоставляет точный префикс аргументов, а не произвольную строку shell. Если совпало несколько правил, действует наиболее строгий результат. Составные shell-команды могут анализироваться по частям только тогда, когда это безопасно и однозначно.

После изменения перезапустите Codex. В поддерживающих это версиях правило можно проверить до использования:

bash
codex execpolicy check --pretty --rules ~/.codex/rules/default.rules -- gh pr view 42

Сначала проверьте наличие execpolicy в своей версии CLI.

Автоматические проверки ​

Пользовательские hooks задаются в ~/.codex/hooks.json, проектные — в .codex/hooks.json или проектном config.toml. Проект должен быть доверенным. Минимальная форма hook:

json
{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "/absolute/path/to/project/scripts/codex-verify.sh",
            "timeout": 120,
            "statusMessage": "Проверка результата"
          }
        ]
      }
    ]
  }
}

Замените абсолютный путь на реальный и храните сам скрипт в Git. Не добавляйте в hook токены или команды публикации.

Полезные события включают SessionStart, UserPromptSubmit, PreToolUse, PermissionRequest, PostToolUse, PreCompact, PostCompact, SubagentStart, SubagentStop и Stop. На дату проверки выполняются command-handlers; объявленные типы prompt/agent и асинхронное выполнение могут быть распознаны конфигурацией, но не исполняться.

Все совпавшие hooks могут запускаться, в том числе параллельно. Поэтому скрипты должны быть идемпотентными и не конфликтовать за один файл.

Доверие и диагностика ​

Команда /hooks показывает найденные hooks и позволяет управлять доверием или отключением. Codex учитывает содержимое доверенного hook; после изменения файла доверие может потребоваться подтвердить снова. При необходимости hooks можно глобально отключить параметром features.hooks = false.

PreToolUse и другие tool hooks полезны как guardrail, но не заменяют sandbox, approvals и системную политику доступа.

Куда дальше ​

Внешние источники ↗ ​