Codex config.toml: где лежит файл, что имеет приоритет и какие примеры безопасны

Codex config.toml не стоит воспринимать как один большой шаблон для копирования. Сначала решите, какой слой владеет настройкой: личные defaults, policy репозитория, разовый override или повторяемый CLI profile.

По состоянию на 21 апреля 2026 года официальные документы OpenAI по Codex config, MCP, authentication и sandbox подтверждают такую модель: ~/.codex/config.toml отвечает за user config, .codex/config.toml работает только в trusted project, а flags и --config могут победить файловые настройки. Локальные команды ниже сверены с установленным codex-cli 0.121.0.

Сначала выберите слой настройки

Если вопрос на самом деле про ChatGPT subscription или API key, начните с руководства по Codex API key vs subscription. Если проблема в квотах, используйте гайд по лимитам Codex.

Что побеждает при конфликте

Текущий порядок precedence выглядит так:

Поэтому симптом "я изменил config.toml, но Codex не слушает" часто означает не ошибку файла, а более сильный слой. Проверьте shell alias, текущий cwd, trust проекта, selected profile и --config.

User config: личные defaults без секретов

Минимальный personal config обычно лучше полного шаблона:

toml
#:schema https://developers.openai.com/codex/config-schema.json

model = "gpt-5.4"
approval_policy = "on-request"
sandbox_mode = "workspace-write"
allow_login_shell = false
cli_auth_credentials_store = "keyring"

Такой файл задает модель, режим подтверждений, рабочий sandbox и хранение credentials. Он не должен содержать access token. auth.json может содержать токены, поэтому его нельзя публиковать или коммитить. API keys и bearer tokens держите в environment variables, keyring или другом private secret manager.

Project config: policy репозитория, а не личное состояние

Project config должен быть скучным и защитным:

toml

#:schema https://developers.openai.com/codex/config-schema.json

approval_policy = "untrusted"
sandbox_mode = "workspace-write"
allow_login_shell = false

developer_instructions = """
Follow this repository's AGENTS.md.
Keep generated assets in documented project paths.
Do not commit credentials, auth state, or provider tokens.
"""

Это shared policy. Оно не раскрывает токен, не включает весь компьютер и не заставляет каждого разработчика жить с вашим личным route. Особенно осторожно относитесь к danger-full-access и approval_policy = "never": вместе они подходят только для уже изолированной automation-среды.

MCP, provider и base URL

Для MCP сначала используйте helper:

bash
codex mcp add docs --env DOCS_TOKEN="$DOCS_TOKEN" -- node ./mcp/docs-server.mjs
codex mcp get docs --json

Если нужен прямой TOML, не записывайте secret как строку:

toml
[mcp_servers.docs]
command = "node"
args = ["./mcp/docs-server.mjs"]
env_vars = ["DOCS_TOKEN"]
startup_timeout_sec = 10
tool_timeout_sec = 60
required = true

Для HTTP MCP server используйте переменную окружения:

toml
[mcp_servers.internal_docs]
url = "https://mcp.example.com"
bearer_token_env_var = "DOCS_MCP_TOKEN"
enabled = true
required = true

openai_base_url меняет endpoint built-in OpenAI provider. Это не доказывает, какой у вас billing contract: subscription, API key и workspace policy остаются отдельными решениями.

Sandbox, approvals, overrides и profiles

Для обычной разработки разумный старт — workspace-write и on-request. read-only хорош для review или диагностики. danger-full-access нужен редко и должен быть объяснен средой, а не удобством.

Разовые проверки лучше делать через flags:

bash
codex --model gpt-5.4-mini
codex --sandbox read-only
codex --config model='"gpt-5.4"'
codex --config sandbox_workspace_write.network_access=true

Profiles полезны для повторяемых CLI modes:

toml
[profiles.review]
model = "gpt-5.4"
sandbox_mode = "read-only"
approval_policy = "on-request"

Запуск:

bash
codex --profile review

Важная граница: OpenAI описывает profiles как experimental и не поддерживаемые IDE extension. Не делайте из них universal policy для всех поверхностей Codex.

Если настройка не применилась

Проверяйте в таком порядке:

Если вы настраиваете desktop/browser interaction, это не та же самая плоскость. Для app permissions и browser workflow смотрите руководство по Codex Computer Use.

FAQ

Где находится Codex config.toml?

User config находится в ~/.codex/config.toml. Trusted projects могут иметь .codex/config.toml. System config может быть /etc/codex/config.toml.

Нужно ли хранить API key в config.toml?

Не в shared project config. Используйте environment variables, OS keyring, private user config там, где это действительно уместно, или официальный authentication flow.

Почему project config не работает?

Проверьте trust проекта, cwd, nested config, selected profile и command overrides. Project config не действует в untrusted project.

Когда использовать --config?

Когда значение нужно только на один запуск: модель, sandbox, web/search behavior или nested key. Если это становится привычкой, перенесите в user config или profile.

Можно ли использовать danger-full-access?

Да, но только в изолированной среде, где broad access действительно нужен. В shared repo это плохой default.

Где официальный schema?

Schema доступна по адресу https://developers.openai.com/codex/config-schema.json; можно добавить #:schema https://developers.openai.com/codex/config-schema.json в начало TOML.