第 7 章 / 共 10 章
config.toml：把每次都要敲的参数固化下来
7.1 配置生效的四层顺序
每次启动都敲 --sandbox workspace-write --ask-for-approval on-request 显然不可持续。Codex 的配置是分层的，从低到高（后面的覆盖前面的）：
- 用户配置：
~/.codex/config.toml，你所有项目的默认值 - 项目配置：项目里的
.codex/config.toml，仅对你标记为受信任的项目加载 - profile：用
--profile <name>显式选择的一组配置 - 命令行参数：
--sandbox、-a、-m，以及用-c内联覆盖任意配置项
理解这个顺序的实际用处是排查问题：当行为和你预期不符时，从最高层往下查——先看你敲的命令行参数，再看有没有激活 profile，再看项目配置，最后才是用户配置。
企业环境里还可能存在管理员下发的受管配置层，它的优先级高于你的个人设置。如果你在公司电脑上发现某些配置怎么改都不生效，问一下管理员。
7.2 最值得先设的几个键
用户配置文件在 ~/.codex/config.toml。下面是一份带注释的起步配置：
# 默认审批策略与沙盒
approval_policy = "on-request"
sandbox_mode = "workspace-write"
# 推理档位：minimal / low / medium / high / xhigh
model_reasoning_effort = "medium"
[sandbox_workspace_write]
# 网络默认关闭，需要装依赖时再临时打开
network_access = false
# 精确放行工作区之外必须可写的目录，比模糊地放开整个沙盒安全得多
writable_roots = ["/tmp/codex-scratch"]writable_roots 值得特别注意。它是第4章那个坑的正解：当 Codex 提示需要写工作区之外的某个路径时，不要用 --yolo 把整道墙拆了，把那一个目录加进 writable_roots 就够了。
注意配置键的写法：模式名用连字符（on-request、workspace-write、read-only、danger-full-access），配置键用下划线（approval_policy、sandbox_mode）。写错了不会得到有用的报错，只会静默使用默认值。
7.3 用 profile 切换工作模式
不同任务需要不同配置。与其每次改文件，不如准备几套 profile，用 --profile <name> 切换。
一套实用的划分：
| profile | 沙盒 | 审批 | 推理档位 | 用于 |
|---|---|---|---|---|
explore | read-only | on-request | low | 读代码、问架构，追求快 |
| （默认） | workspace-write | on-request | medium | 日常开发 |
deep | workspace-write | on-request | high | 疑难 bug、复杂重构 |
ci | read-only | never | low | 自动化里的只读检查 |
临时试一个配置而不想改文件时，用 -c 内联覆盖：
codex -c model_reasoning_effort=\"high\" "重构这个模块的错误处理"
7.4 模型与推理档位：别写死，学会查
Codex 支持多个模型，且模型名和退役时间变动很快。因此本教程不列具体型号，只教你怎么查和怎么选。
查当前可选项，在会话里执行：
/model它会列出当前账号可用的模型和推理档位。推理档位从低到高大致是：minimal、low、medium、high、xhigh。不指定模型时，Codex 会使用推荐模型。
选择原则：
- 先调推理档位，再换模型。同一个模型从
low提到high带来的差异，往往比换模型更明显，且更容易预测。 - 读代码、回答问题用低档位。这类任务瓶颈在读取而非推理，高档位只是变慢变贵。
- 调试和重构用高档位。这类任务的价值全在”想清楚”这一步。
- 不确定就用默认。默认推荐模型是官方在能力和成本之间调过的结果。