Codex config.toml 配置：文件放哪里、谁优先、哪些示例才安全

先决定配置层，而不是先打开文件

个人默认值放在 ~/.codex/config.toml，可信仓库策略才放 .codex/config.toml，临时实验用命令行覆盖，重复使用的 CLI 模式再放进 profile。

不要把 API key、bearer token 或 auth.json 写进共享项目配置。配置文件应减少重复选择，而不是把密钥或过宽权限写死。

优先级：冲突时到底谁赢

配置没有生效时，先查当前命令是否带有 --config 或 --profile，再查当前目录和项目 trust 状态，最后检查更近的项目配置。命令行和更具体的项目层通常会覆盖个人默认值。

我改了 config.toml 但没生效，通常不是 Codex 忽略了文件，而是另一层配置正在生效。

个人配置：只放跟你有关的默认值

个人配置适合放模型、审批策略、沙盒偏好和本机认证方式。保持短小，不要把只对某个仓库生效的策略塞进用户层。

项目配置：写共享策略，不写私人状态

项目配置可以描述仓库规则、默认沙盒和项目说明，但不应保存账号 token、本机路径或私人路由。尤其不要把 danger-full-access 与 approval_policy = "never" 当作共享默认值。

[sandbox]
mode = "workspace-write"

[approval]
policy = "on-request"

MCP、模型和 provider：示例要短，密钥要间接

配置 MCP 时优先使用 codex mcp add 这类 helper，让 Codex 生成不容易写错的 TOML。模型默认值适合长期使用时写入文件，只试一次的模型或权限变化用命令行参数更稳妥。

沙盒、审批和 profile

日常本地开发通常从 workspace-write + on-request 开始；代码审查或只读排查可以使用 read-only。profile 适合重复使用的 CLI 预设，但目前属于 CLI 便利功能，IDE extension 不一定支持。

配置没生效时按这个顺序查

1. 当前命令是否带 --config / --profile
2. 项目是否 trusted
3. 是否存在更近的 .codex/config.toml
4. 当前目录是否在预期项目内
5. 最后才检查个人 ~/.codex/config.toml

FAQ

• 用户配置默认位于 ~/.codex/config.toml，可信项目可以有 .codex/config.toml。
• API Key 不应写进共享 config.toml，应使用环境变量、系统凭据存储或 secret 管理。
• 临时实验、一次性模型和临时沙盒变化适合使用 --config。
• 官方 schema：https://developers.openai.com/codex/config-schema.json