Ключи config.toml задают почти всё постоянное поведение Codex, и их удобнее понимать по группам, а не сплошным списком. Динамический именованный сегмент в путях ключей обозначают как <name> - например, для профиля разрешений или MCP-сервера. Важная оговорка справочника: многие ключи экспериментальные, enterprise-only или специфичны для поверхности, и наличие ключа в схеме не является рекомендацией его включить. Полный и точный набор для вашей версии - в официальной Configuration Reference.

Ключи модели, разрешений и sandbox - ядро поведения. Модель задают через model, model_reasoning_effort и personality; разрешения - через default_permissions и секции [permissions.<name>] с filesystem и network; подтверждения - через approval_policy и approvals_reviewer; sandbox - через sandbox_mode и [sandbox_workspace_write] с network_access и web_search. Именно эти ключи определяют, что агент делает без спроса и что вообще может тронуть, поэтому их правят особенно осознанно.

Ключи расширения и интерфейса подключают компоненты и настраивают вид. MCP задают секциями [mcp_servers.<name>] с url, таймаутами и tool policy; субагентов и роли - секцией [agents]; hooks - секцией [hooks] и файлом hooks.json; интерфейс - секцией [tui] со строкой статуса и keymap. Отдельно стоит requirements.toml: это не обычный слой, а admin-enforced ограничения, которые нижние слои перекрыть не могут.

Полезно один раз свести ключевые группы в таблицу. Ниже - карта от модели до интерфейса и managed-политики. Пользоваться справочником стоит с общей оговоркой: наличие ключа не означает совет его включить, а редкие поля - особенно с experimental, dangerously или bypass в смысле - проверяют по связанной reference-странице перед использованием. Схему сверяют с /debug-config и официальной документацией, а не полагаются на память о ключе.