Разрешения и hooks в Codex: как не дать агенту публиковать раньше проверки

Самая опасная автоматизация не та, которая ничего не умеет. Опаснее та, которая умеет почти все и не знает, где остановиться. В контент-заводе это особенно заметно: написать черновик можно быстро, но публикация, визуал, социальная очередь и внешние действия должны идти только после gates.

В документации Codex для этого есть несколько слоев: разрешения, rules и hooks. Если говорить по-русски, это не “настройки для разработчиков”, а карта ответственности: что агент может сделать сам, где должен спросить, а что ему запрещено даже пытаться делать.

Почему “пусть сам делает” плохо масштабируется

Когда публикаций мало, кажется, что ручной контроль очевиден. Человек видит черновик, видит картинку, нажимает publish. Но как только появляется очередь, автоматизация и несколько каналов, возникает риск неправильного порядка: текст готов, визуал не готов; пост поставлен, статья еще не прошла live audit; источник не проверен, но заголовок уже обещает слишком много.

Именно поэтому контент-заводу нужны не только навыки написания, но и механические границы. Codex может быть очень хорошим исполнителем, но он не должен сам решать, что отсутствие проверки “и так нормально”.

Что официально описывает Codex

Документация по permissions описывает профили доступа: от read-only до workspace и danger-full-access, плюс пользовательские профили с правилами для файловой системы и сети. Это отвечает на вопрос: куда Codex вообще может смотреть и писать.

Rules управляют командами вне sandbox: можно разрешить, запретить или требовать prompt для конкретного префикса команды. Это отвечает на вопрос: какие действия слишком рискованны, чтобы проходить молча.

Hooks позволяют запускать свои проверки в событиях агентного цикла: перед использованием инструмента, после него, при запросе разрешения, перед остановкой, при старте сессии и других моментах. Это отвечает на вопрос: какая проверка должна сработать не “когда вспомним”, а автоматически.

Для редакции это переводится просто: permissions задают территорию, rules задают опасные команды, hooks задают обязательные проверки.

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

Чтобы Codex помог построить карту gates, дайте ему не техническую мечту, а список реальных действий:

Такой вход понятен владельцу процесса. Не нужно знать синтаксис hooks, чтобы сформулировать, где должен стоять контроль.

Какой артефакт должен вернуть Codex

Хороший результат - карта границ, а не россыпь конфигов. Например:

Действие: публикация статьи
Разрешение: только после passed ARTICLE_TEXT_REVIEW
Visual gate: verified Codex visual media required
Live gate: LIVE_PUBLIC_BODY_AUDIT passed
Social gate: enqueue only through hosted ArticleFactory
Human decision: можно ли выпускать материал с текущим углом и визуалом

После этого Codex уже может предложить, где это хранить: в AGENTS.md как правило проекта, в skill как шаг процесса, в hook как автоматическую проверку, в permission profile как ограничение доступа.

Здесь важно не перепутать уровни. AGENTS.md говорит, что публикация без визуала запрещена. Skill делает пакет. Hook проверяет, что файл review действительно passed. ArticleFactory получает только готовый пакет и не “додумывает” обложку сам.

Как проверить без программирования

Непрограммисту нужна таблица “можно / спросить / нельзя”. Если Codex возвращает только конфиг, попросите его перевести конфиг в рабочую карту.

Проверка такая:

1. Есть ли список действий, а не общая фраза “работать безопасно”?
2. Для каждого действия указано allow, prompt или forbidden?
3. Есть ли причина, почему действие ограничено?
4. Есть ли файл или gate, который подтверждает готовность?
5. Понятно ли, кто принимает финальное решение?

Если публикация стоит в allow без дополнительных gates, это плохая архитектура. Агент может быть быстрым, но редакция не должна догонять уже опубликованную ошибку.

Как это связано с визуалом и очередью

В нашем контент-заводе визуал - хороший пример. Codex может написать статью раньше, чем готова обложка. Это нормально. Но публикация и Telegram/VK не должны стартовать, пока нет verified media. Значит, состояние textreviewpassedblockedforvisualmedia - не поломка, а честный gate.

Проблема начинается, если ArticleFactory пытается “спасти” ситуацию и сам рисует fallback-картинку. Тогда качество переезжает из редакции в транспортный слой. Поэтому правильная граница такая: Codex skills создают и проверяют визуал, ArticleFactory только публикует и ставит в очередь готовое.

Мы уже разбирали MCP и границы доступа как карту внешних инструментов. Hooks и permissions - соседний слой: они удерживают не только доступ к инструментам, но и порядок действий.

Мини-карта gates для контент-завода

Это и есть рабочая архитектура: не “Codex делает все”, а “Codex делает видимые артефакты, gates решают порядок, человек утверждает смысл”.

Человеческое решение

Разрешения и hooks не заменяют доверие. Они делают доверие проверяемым. Человек решает, где проект готов к автоматизации, а где риск слишком высок.

Для статьи это может звучать так: Codex может писать, проверять, собирать визуальный бриф, готовить публикационный пакет и ставить задачу визуальной студии. Но публиковать без review, verified media и live audit нельзя. Не потому что Codex плохой. А потому что хороший контент-завод не должен зависеть от удачи.