Codex 的 config.toml 修改后不生效，通常不是 TOML 文件坏了，而是配置被更高优先级覆盖、项目尚未被信任，或旧会话仍在使用启动时的设置。先确认改的是哪一层，再继续排查。
先对照真实的配置优先级
Codex 从高到低按以下顺序解析同名设置：
- 当前命令参数和
-c key=value； - 项目内
.codex/config.toml，从仓库根目录向当前目录逐层加载，距离当前目录最近的值优先； --profile选中的个人配置；- 用户级
~/.codex/config.toml； - Unix 系统级
/etc/codex/config.toml； - 内置默认值。
例如用户配置写了 sandbox_mode = "workspace-write"，启动命令却带 --sandbox read-only，本次运行一定以命令行为准。仓库项目配置则会覆盖用户配置。
用一次性参数定位配置层
先用命令行临时覆盖同一个设置。如果临时值有效，说明 Codex 支持该配置，问题集中在文件位置、优先级或信任状态。
codex -c model_reasoning_effort="high"再用严格配置检查，让当前版本遇到不认识的字段时直接报错：
codex --strict-config功能开关可用 codex features list 查看有效状态；工作目录和沙箱范围在会话中用 /status 检查。
项目配置完全被忽略时看信任状态
未被信任的项目不会加载项目内 .codex/ 配置层，其中也包括项目 hooks 和 rules。此时用户级配置仍会加载，所以常见表现是“全局设置有效，仓库设置无效”。确认打开的是正确仓库根目录，再通过启动提示或 /permissions 完成可信目录确认。
受组织管理的设备还可能有 requirements.toml 约束。管理员禁止的沙箱或审批模式，个人配置无法强行覆盖；这时应查看组织策略。最后新开 CLI 会话或重新加载 IDE 扩展，一次只调整一个位置再验证。
