直接答案
把持久默认值、项目约束与单次命令覆盖分开管理，减少配置漂移和升级后的隐性行为变化。
这篇内容解决什么问题
查找、编辑并验证 Codex CLI config.toml 配置
理解配置层级与职责
用户级 ~/.codex/config.toml 适合放个人默认模型、provider 和交互偏好。项目 .codex/config.toml 适合受信任仓库的团队设置，命令行参数适合只影响当前调用的实验。
不要把 API Key 与普通设置混放。认证数据应进入认证机制或 Secret 存储，config.toml 只描述行为和请求路由。
定位配置而不暴露认证数据
默认用户配置位于 ~/.codex/config.toml。Windows 的 ~ 对应用户主目录。若设置了 CODEX_HOME，应以该目录为准。
诊断时优先使用 doctor 与 features，而不是递归打印整个 ~/.codex 目录。auth.json 可能包含密钥，不应出现在终端分享或工单附件中。
CODEX_DIR="${CODEX_HOME:-$HOME/.codex}"
printf "CODEX_HOME=%s\n" "$CODEX_DIR"
codex doctor --summary
codex features list
codex exec --strict-config --ephemeral -s read-only "只报告当前模型和沙箱模式，不运行命令。"从少量明确字段开始
配置项越多，升级时需要验证的行为越多。先设置稳定且能够解释的字段，其他选项在确有需求时再依据当前配置参考加入。
模型标识必须被当前 provider 接受。下面示例展示 CodeNodex 当前 Codex 默认模型，但 provider 的完整配置在模型与 provider 专篇中说明。
model = "gpt-5.6-sol"
model_reasoning_effort = "high"
sandbox_mode = "workspace-write"
approval_policy = "on-request"先用单次覆盖验证配置
-c key=value 会把 value 按 TOML 解析，并只影响当前调用。模型、工作目录、沙箱和审批有专用参数时，应优先使用专用参数以提高可读性。
验证有效后再写入配置，能够避免一次实验永久改变所有仓库。
codex -m gpt-5.6-sol -s read-only -a untrusted "只分析失败测试。"
codex -c model_reasoning_effort=high "比较两种修复方案，不要修改文件。"
codex -s workspace-write -c sandbox_workspace_write.network_access=false "仅依据本地仓库回答。"编辑前备份，编辑后结构化验证
手工编辑前创建带时间戳的备份，不要覆盖唯一的旧副本。若使用 CodeNodex CLI，setup 已包含解析、备份、原子写入和失败回滚。
TOML 的表层级和重复键容易导致解析失败。修改后运行 doctor，并通过一个只读任务验证最终生效值。
CODEX_DIR="${CODEX_HOME:-$HOME/.codex}"
cp "$CODEX_DIR/config.toml" "$CODEX_DIR/config.toml.bak.$(date -u +%Y%m%dT%H%M%SZ)"
${EDITOR:-vi} "$CODEX_DIR/config.toml"
codex doctor --summary
codex -s read-only "报告当前模型与沙箱模式，不要读取或输出任何密钥。"控制版本升级与配置漂移
升级 CLI 后检查 release 说明、本机帮助与 doctor。删除未知字段之前先确认它是否来自团队策略或仍被旧环境使用。
把关键默认值及其原因记录在团队文档中，定期移除已经恢复为官方默认的冗余项。配置越精简，跨机器复现越容易。
- 记录 Codex 版本和配置验证日期。
- 对 config.toml 的手工变更保留 diff。
- 不要长期启用未使用的实验 feature。
- provider 模板与模型列表应来自同一维护来源。
官方来源与核验范围
本文以公开官方文档为事实依据；命令和配置可能随客户端版本变化，执行前请同时核对对应来源。
查看技术核验方法