快速答案
- 不改任何东西就能查当前默认模型：Codex 启动时欢迎横幅会打出活动模型，会话内用 /status 查看，codex doctor --summary 则报告加载了哪些配置文件。
- 只想本次会话换模型就用 /model 斜杠命令——会话一结束切换就失效，config.toml 里的默认值自动回归。
- 想永久设置就在 ~/.codex/config.toml 里写 model = "gpt-6.1-sol"，再配 model_reasoning_effort = "high" 控制它思考的深度。
- 受信任的项目可以带自己的 .codex/config.toml 覆盖你的用户级默认值，嵌套子目录还能再覆盖一层——而 CLI 标志或 -c 覆盖永远赢。视频用一张作用域表把整条优先级链验证了个遍。
- Codex CLI 0.161.0（2026 年 10 月 7 日）把 GPT-6.1 Sol 设为内置目录和 Amazon Bedrock 目录的默认模型——升级之后，你的默认值可能已经悄悄变了。
Codex CLI Setup & Configuration: Which Setting Wins?
频道：Coding With Chuck10:12
Config reference — official documentation
文档：developers.openai.com/codex
Release rust-v0.161.0 — default model swap
版本：github.com/openai/codex
录屏在一次性 CODEX_HOME 实验环境里用 gpt-5.6-terra、gpt-5.6-sol 和 gpt-5.6-luna 作示例值；它演示的键——model、approval_policy、sandbox_mode、projects trust_level——都是官方参考文档里真实的 config.toml 键。会话内的 /model 和 /status 命令来自官方斜杠命令文档。
视频画面版权归 Coding With Chuck 所有，此处以分步文档形式嵌入，注明出处并附深度链接。
一步一步设置 Codex 默认模型
搞清楚你实际在跑哪个模型
- 1
从官方入口安装或打开 Codex
一切从 chatgpt.com/codex 开始——录屏先打开这个入口和它的 Download 按钮，然后才碰终端。如果你已经装了 CLI，直接跳过；如果你感觉默认模型自己变了，先查版本，因为内置目录会随版本变动。
chatgpt.com/codex 入口页，带 Download for Windows 按钮在 1:30 观看 - 2
确认你的 shell 跑的是哪个 codex
先别急着怪配置，确认你跑的就是你以为的那个 Codex。在 PowerShell 里，Get-Command codex 解析到 codex.ps1 并显示安装路径；macOS 或 Linux 上用 which codex 同理。装了多份（npm 加独立二进制）是"改了配置却像没生效"的经典原因。
Get-Command codex 解析出启动脚本和来源路径在 2:00 观看 - 3
查版本和登录状态
跑 codex --version，再跑 codex login status。录屏里报的是 codex-cli 0.146.1 和 "Logged in using ChatGPT"。版本在这里很关键：默认模型随 CLI 内置目录走，两台版本不同的机器对"默认模型是什么"都可能各执一词。
一屏内同时看到 codex --version 和 codex login status在 2:40 观看 - 4
用 codex doctor 检查生效配置
codex doctor --summary 会打印健康报告：录屏里有一条 "mixed auth signals" 提示（ChatGPT 登录加 API key 环境变量），runtime、install、git、terminal 都是绿色对勾，Configuration 一节确认配置已加载。这是确认你的配置文件到底有没有被读到的最快办法。
doctor 报告里的认证提示和绿色环境检查在 3:00 观看
在 config.toml 里设默认值——用户级、项目级、子目录
- 5
定位你的 Codex home
用户级设置放在 ~/.codex，而 CODEX_HOME 环境变量可以把 Codex 指向完全别的地方——录屏特意建了一个一次性实验目录并把 CODEX_HOME 指过去。如果同事或脚本曾经设过 CODEX_HOME，你对 ~/.codex/config.toml 的修改就会落进一个 Codex 根本不读的文件。
安装脚本宣告隔离的 CODEX_HOME 实验环境在 4:30 观看 - 6
打开用户级 config.toml
Codex home 里面是 config.toml——官方配置参考文档记载的正是这个文件。录屏在 VS Code 里展开 codex-home 文件夹并选中 config.toml。在正常机器上它就是 ~/.codex/config.toml；还没有就新建一个，并保持 TOML 语法（值加引号，不带逗号）。
VS Code 里选中 codex-home 文件夹的 config.toml在 4:53 观看 - 7
在用户级设默认模型
加上 model = "gpt-5.6-terra"——录屏的示例，用的是那个年代的目录模型；今天内置默认已是 gpt-6.1-sol，所以填你在 /model 里看到的精确 ID。同一个文件里还有 approval_policy = "on-request" 和 sandbox_mode = "workspace-write"，以及一个 [projects.'D:\...\config-lab'] trust_level = "trusted" 块，标记哪些文件夹可以加载自己的项目配置。
model、approval_policy、sandbox_mode 和受信任项目块在 5:00 观看 - 8
按项目覆盖模型
受信任的仓库可以带自己的 .codex/config.toml。录屏在 config-lab 根目录加了一个，写 model = "gpt-5.6-sol" 和注释 "Trusted repository default for this demonstration"——从此在这个仓库里启动的会话用 Sol，其他地方仍是 Terra。记住文档的规则：项目文件不能覆盖 model_provider 这类机器本地键，所以 provider 配置留在用户级。
项目的 .codex/config.toml 固定了 gpt-5.6-sol在 5:25 观看 - 9
给子目录再嵌一层覆盖
再往深一层：config-lab/tools 有自己的 .codex/config.toml，写 model = "gpt-5.6-luna" 和注释 "More specific setting for work launched under tools/"。受信任的项目配置从仓库根一直作用到工作目录，所以你从哪个最具体的文件夹启动，就由它说了算。
tools/.codex/config.toml 为该子树固定 gpt-5.6-luna在 5:50 观看 - 10
证明哪一层赢了
录屏用一个 run-demo 脚本收尾，打出一张 "Effective model" 表：user → terra，project-root → sol，nested-project → luna，cli-override → terra。整条优先级链一屏看尽——命令行标志和 -c 覆盖压过嵌套文件夹，嵌套文件夹压过项目根，项目根压过用户配置。
逐作用域的有效模型表，下面是 doctor 提示在 6:00 观看
会话内切换、推理力度与 0.161.0 的默认值更换
- 11
会话内用 /model 换模型
会话里 /model 打开选择器随时换模型，/status 则报告当前生效的模型和推理力度。会话切换按设计就是临时的——退出重启，config.toml 的默认值重新接管。所以先拿 /model 试模型，满意了再固定，最稳妥。
- 12
了解 0.161.0 的默认值更换（2026-10-07）
2026 年 10 月 7 日发布的 Codex CLI 0.161.0 写明："GPT-6.1 Sol is now the default model in the bundled and Amazon Bedrock catalogs." 如果从没设过 model 键，一次升级就悄悄把你挪了过去。想保住旧默认，就在 ~/.codex/config.toml 里显式写上，并用 model_reasoning_effort 调深度（文档示例是 "high"）。团队还应知道 agents.default_subagent_model 为派生的智能体设默认模型，review_model 则覆盖 /review 用的模型。
默认模型不生效时
你改了配置文件，Codex 启动还是旧模型。先别急着再改一遍，把这份清单过一遍——原因几乎总是另一层配置压过了你的。
- 1文件和启动位置的作用域不匹配——项目里的 .codex/config.toml 会覆盖用户级 ~/.codex/config.toml，嵌套的又压过项目根。在你实际启动的那个文件夹里跑 codex doctor，看它报告加载了哪些配置。
- 2CLI 标志或一次性 -c 覆盖压过所有文件——如果包装脚本、别名或 IDE 插件用 --model 或 -c model=... 启动 codex，你的配置根本没机会说话。查一下命令到底是怎么被调用的。
- 3CODEX_HOME 指向了别处——当 CODEX_HOME 环境变量把 home 目录搬走时，改 ~/.codex/config.toml 完全没用，视频里的实验环境干的就是这事。先 echo 一下这个变量，再怪解析器。
- 4项目不受信任——不受信任文件夹里的 .codex/config.toml 会被整个跳过。信任要在用户配置里通过 projects.'<path>'.trust_level = "trusted" 授予，录屏的用户文件里就是这么写的。
- 5机器本地键写进了项目文件——model_provider、model_providers、profile 和 profiles 在项目级配置里按设计被忽略。如果你本想按项目挂自定义 provider，把它挪回用户级，项目里只覆盖模型 ID。
- 6模型 ID 打错或已改名——model 值必须和目录完全一致（0.161.0 重新洗牌了内置目录和 Bedrock 目录）。打开 /model 复制精确 ID，粘进 config.toml，别凭记忆手敲。
一旦文件分层理顺了，行为就完全可预测：用户默认，然后 profile，然后从仓库根到目录的受信任项目配置，最后 CLI 标志。录屏那张作用域表值得在你自己的机器上复现一遍——跑之前把四行都预测出来，从此再也不用猜 Codex 会用哪个模型。