Codex
Codex CLI 升级后核对指南：默认模型、功能开关与认证入口
升级 Codex CLI 之后，默认模型、功能开关、MCP 认证入口和启动行为都可能与升级前不同。本文按「版本 → 模型目录 → 功能开关 → 认证入口 → 已知修复」的顺序，整理出一套可在本机逐条执行的核对流程，并说明如何用 codex debug models、codex features list 等命令确认实际生效的配置。
Codex CLI 更新频繁，很多人执行完 npm update 就直接接着用，不会先去读发布说明。问题在于，随 CLI 一起分发的模型目录会在版本之间调整默认模型，功能开关的默认值也会变。如果本机没有任何显式配置，升级那一刻起，实际对话的模型可能已经换了。要弄清「升级后到底变了什么」，不必靠猜，CLI 本身就提供了若干查询命令。本文按「先看版本、再看模型、然后看功能开关、接着看认证入口、最后看已知修复」的顺序，整理成一套可以逐条执行的核对流程。适合日常使用 Codex CLI、并且已经或即将升级到 0.161～0.162 系列的开发者。文中涉及的价格、配额、模型可用范围等信息会随时间变化，请以官网当前信息为准。想先了解这个工具的整体定位，可以看 Codex 的工具页。
准备工作
这套核对流程对环境的依赖很低，大部分命令在未登录、无配置文件的状态下也能执行。开始之前确认以下几件事。
- Node.js 与 npm：Codex CLI 通过 npm 包
@openai/codex分发，需要能执行npm view与npm install。 - 一个隔离的安装目录（可选但推荐）：如果想避免影响日常使用的全局安装，可以在仓库之外的临时目录里做本地安装，并把
HOME与CODEX_HOME一并指向该目录，这样配置文件和缓存都不会污染原有环境。 - 不需要事先登录：
codex debug models与codex features list在既没有 ChatGPT 登录、也没有设置 API 密钥、且不存在配置文件的状态下即可运行。只有涉及 TUI 交互的功能（例如会话内的 MCP 登录、语音设备选择、任务固定）才需要登录。 - 明确目标版本：本文的核对点集中在 0.161.0、0.162.0、0.162.1 三个版本上。安装时建议显式写出版本号，而不是依赖
latest或@alpha这类浮动标签。
如果平时是全局安装，用下面这种写法把版本钉住，便于把本文的说明和自己机器上的实际行为对上：
npm install -g @openai/codex@0.162.1如果只想在临时目录里试，去掉 -g，并在该目录下执行即可。
操作步骤
第一步：确认实际安装的版本与 dist-tag
先确认本机 CLI 的版本，同时看一下 npm 上的 dist-tag，判断自己是否无意中装到了 alpha 版本。
npm view @openai/codex dist-tags --json
npm view @openai/codex time --json输出中值得关注的是 latest 与 alpha 两个标签分别指向哪个版本，以及 time 字段里各版本的发布时间。如果 alpha 标签指向的版本号比 latest 更高，说明用 @alpha 或范围写法安装时，拿到的可能并不是 0.162 系列。发布时间的先后也能帮助判断某个版本是稳定线还是预发布线。
安装完成后，用下面的命令确认实际生效的版本：
codex --version输出形如 codex-cli 0.162.1。如果这里显示的版本与预期不符，先解决版本问题，再往下做其余核对，否则后面看到的模型目录和功能开关可能来自另一个版本。
codex --help 的子命令列表里还会出现 update 与 doctor。这两个子命令的具体行为不在本文的核对范围内，需要时请以官方说明为准。
第二步：查看随 CLI 分发的模型目录
默认模型是否变化，可以通过 codex debug models 观察。这个子命令输出 CLI 内置的模型目录，在无认证、无配置文件的状态下也能执行。
codex debug models输出是 JSON，字段较多。下面是从输出中摘出的部分条目，用于说明各字段的含义（并非全部条目）：
| slug | display_name | visibility | priority | context_window | default_reasoning |
|---|---|---|---|---|---|
| gpt-6.1-sol | GPT-6.1-Sol | list | 1 | 272000 | low |
| gpt-6-astra | GPT-6-Astra | list | 2 | 272000 | low |
| gpt-6-sol | GPT-6-Sol | list | 3 | 272000 | medium |
| gpt-6-luna | GPT-6-Luna | list | 4 | 272000 | medium |
| gpt-5.6-sol | GPT-5.6-Sol | list | 5 | 272000 | low |
| gpt-5.6-terra | GPT-5.6-Terra | list | 8 | 272000 | medium |
| gpt-5.6-luna | GPT-5.6-Luna | list | 9 | 272000 | medium |
| gpt-daybreak-blue-latest | Daybreak Blue | hide | 11 | 272000 | low |
| gpt-daybreak-red-latest | Daybreak Red | hide | 12 | 372000 | medium |
| gpt-5.5 | GPT-5.5 | list | 13 | 272000 | medium |
| codex-auto-review | Codex Auto Review | hide | 43 | 272000 | medium |
从这张表能读出几件事。
priority 最小的条目排在前面。 gpt-6.1-sol 的 priority 为 1，紧随其后的是 gpt-6-astra。需要说明的是，这个输出本身并不会直接声明「默认模型就是它」；「priority 最小者即默认」是从目录排序得出的推断，它与发布说明中「默认模型改为 GPT-6.1 Sol」的表述一致。若要亲眼确认 TUI 中默认选中的模型，需要登录后启动交互界面查看，这一步不在本文范围内。
default_reasoning 并不统一。 gpt-6.1-sol 是 low，而 gpt-6-sol 是 medium。也就是说，模型切换的同时，未显式指定推理强度时的默认值在目录层面也可能随之改变。如果升级后感觉响应速度或推理深度与之前不同，除了模型本身，也值得检查这一项。
visibility 为 hide 的条目默认不出现在可选列表中。 Daybreak Blue 与 Daybreak Red 都是 hide，这与它们属于 opt-in 功能是一致的。
第三步：注意目录中的 context_window 与 API 文档的差异
模型目录里最容易被忽略的是 context_window。上表中绝大多数模型都是 272000，只有 Daybreak Red 是 372000。这说明该值不是全局固定常量，而是按模型在 CLI 侧单独维护的。
这个数字与 API 文档中同一模型的上下文长度并不是一回事。以 GPT-6.1 Sol 为例，API 模型页给出的 context window 为 1,050,000 tokens（最大输入 922,000），最大输出 128,000 tokens，而 CLI 目录里是 272,000。两者相差约四倍。如果只按 API 页面估算，认为在 Codex 里也能直接传入百万级 token 的上下文，前提就可能不成立。
至于这个差异在运行时如何体现——例如超过 272,000 时 CLI 是否会压缩或截断——需要在登录状态下实际传入长上下文才能验证，仅凭目录输出无法判断。可以确定的是：CLI 目录中的值与 API 的最大值属于两套口径，做成本估算时不宜直接套用 API 页面的上下文长度。
另外，API 模型页还写明：输入超过 272K tokens 的请求，整个请求的输入与缓存费用按两倍计、输出按 1.5 倍计。这个 272K 与 CLI 目录中的 272000 数值相同，但 CLI 是否据此设定该字段，官方并未说明。具体计费规则请以官网当前信息为准。
第四步：固定模型，避免升级带来的行为漂移
如果不想跟随默认模型切换，可以显式指定模型。CLI 中常用的方式有两种：会话内使用 /model 命令切换，或在启动时通过参数指定：
codex --model gpt-6-sol团队协作场景下尤其建议显式固定模型，否则每次升级都可能改变默认行为，排查问题时难以区分是代码问题还是模型变化。
还要注意，未指定模型时最终选中哪一个，也可能受订阅方案影响。官方 models 页面并未直接写出默认模型名称，而是表述为「recommended model」，并且 GPT-6.1 Sol 对部分方案不开放。此外，官方页面还提到 GPT-5.5 将在 2026 年 10 月 14 日在所有方案中退役（API 不受影响）。这些都属于会变化的信息，使用前请核对官网当前说明。
第五步：核对功能开关的默认值
功能开关的默认状态可以用下面的命令查看：
codex features list输出为三列：名称、stage、是否默认启用。与本次升级相关的几行如下（摘录）：
api_key_cyber_access_programs stable false
cli_daybreak under development false
in_app_voice stable true
worktrees stable truecli_daybreak 默认关闭。 它处于 under development 阶段，默认值为 false。要启用 Daybreak，需要显式指定 --enable cli_daybreak，或在配置中设置 features.cli_daybreak=true。注意 daybreak=true 这种写法不会生效。这与目录中 Daybreak 系列 visibility 为 hide 是一致的。另外，若要使用自动的 Cyber 路由，还需要满足特定的 ChatGPT 登录与 OpenAI provider 组合条件。
in_app_voice 默认开启。 它处于 stable 阶段，默认值为 true。语音会话中的麦克风、扬声器、输入通道选择，其设置会保存在本地。
worktrees 默认开启。 同样处于 stable 阶段，默认值为 true。托管式 Git worktree 工具在 worktrees 功能启用时，对受信任的本地项目可用。由于默认开启，被标记为受信任的项目无需额外配置就可能进入该范围。worktree 的具体用法与手动执行 git worktree 的区别不在本文讨论范围内，这里只需确认它的默认状态。官方 worktree 文档中提到的存储位置与保留数量属于桌面应用侧的说明，不宜直接当作 CLI 的规格。
不必每次升级都把所有开关过一遍。更高效的做法是：只把发布说明里提到的名称拿到 codex features list 的输出里对照，确认默认值即可。
第六步：确认 MCP 与本体认证的入口
0.161.0 起，会话内可以通过 /mcp login <name> 完成 MCP 服务器的认证。除了 TUI 内的命令，CLI 子命令层面也提供了认证入口，可以先看帮助：
codex mcp --help子命令列表中会出现 list、get、add、remove、login、logout。也就是说，不打开 TUI，也能从 shell 完成 MCP 服务器的登录与登出：
codex mcp login
codex mcp logout根据官方 MCP 文档，codex mcp login 支持 --no-browser、--scopes、--oauth-client-registration <AUTO|CIMD|DCR> 等选项，这些在 codex mcp login --help 中也能看到。TUI 内的 /mcp login 是否与子命令行为完全一致，需要自行验证。是否能在非交互环境中使用（例如脚本或 CI），也建议先实测再决定。
Codex 本体的认证走 codex login，其帮助中列出了 status 子命令以及 --with-api-key、--with-access-token 等选项。升级后如果怀疑认证失效，先执行：
codex login status这样可以把认证问题与模型、MCP 问题区分开，缩小排查范围。
另外需要注意，codex mcp-server 已在 2026-08-24 被标记为弃用，并于 2026-09-05 移除。如果手头的旧流程还在使用它，需要单独安排迁移，这与本次版本升级是两件事。
第七步：了解 0.162.1 修复的启动失败条件
0.162.1 的发布说明列出两项修复：一是多行异步提问导致 TUI 崩溃的问题（保留换行与完整超链接目标）；二是当后台正在运行的服务端与 CLI 的功能设置不一致时，不再导致启动失败——兼容性检查只在 CLI 显式覆盖功能设置时才生效。
第二项与第五步直接相关。在修复之前，后台服务端与本地 CLI 的功能设置存在差异时，启动本身可能失败。升级到 0.162.1 后，仅存在这种差异不会再阻断启动；但按发布说明的表述，通过 --enable 等方式显式覆盖功能设置时，仍会经过兼容性检查。因此，如果习惯用 --enable cli_daybreak 这类方式启动，最好确认后台服务端的设置与之对齐，出问题时更容易定位。
0.162.0 还包含其他修复与新增，例如新 TUI 线程中服务端模型与推理默认值的处理、apply_patch 对 CRLF 的保留、Linux 与 Windows 的沙箱、Retry-After 的处理、PowerShell 安装器的校验和等。如果仍停留在 0.161 系列，升级到 0.162.1 可以一次性获得这些修复。
一个完整示例
下面把上述步骤串成一个最小可执行的核对流程。假设目标是确认本机安装的 0.162.1 是否把默认模型切到了 GPT-6.1 Sol，以及 Daybreak 是否仍处于关闭状态。
# 1. 在临时目录中做隔离安装
mkdir -p /tmp/codex-check && cd /tmp/codex-check
export HOME=/tmp/codex-check/home
export CODEX_HOME=/tmp/codex-check/codex-home
npm install @openai/codex@0.162.1
# 2. 确认版本
./node_modules/.bin/codex --version
# 3. 查看模型目录，关注 priority 与 context_window
./node_modules/.bin/codex debug models
# 4. 查看功能开关默认值
./node_modules/.bin/codex features list
# 5. 确认 MCP 与本体认证入口存在
./node_modules/.bin/codex mcp --help
./node_modules/.bin/codex login --help执行后逐项对照：
- 第 2 步输出应为
codex-cli 0.162.1。若版本不符，先检查是否被 PATH 上其他安装抢先。 - 第 3 步输出中，
gpt-6.1-sol应位于 priority 1，其context_window为 272000，default_reasoning为 low。 - 第 4 步输出中，
cli_daybreak应为 false，worktrees与in_app_voice应为 true。 - 第 5 步输出中，应能看到
login、logout子命令，以及status等选项。
如果希望继续使用旧模型，在正式环境中启动时显式指定即可：
codex --model gpt-6-sol如果确实需要 Daybreak，则显式开启：
codex --enable cli_daybreak或在配置中写入 features.cli_daybreak=true，注意不要写成 daybreak=true。
注意事项
版本与标签：latest 与 alpha 指向不同版本，且 alpha 可能比 latest 更新。用 @alpha 或范围写法安装时，可能拿到非 0.162 系列。安装时显式写出版本号最稳妥。
版本显示不一致：如果 codex --version 显示的仍是旧版本，通常是全局与本地各装了一份，而 PATH 上先命中的是旧的那份。用 which codex 确认实际调用的二进制，再以显式版本号重新安装。
模型目录不等于运行时确认：codex debug models 输出的是随 CLI 分发的目录，priority 最小者为默认只是从排序得出的推断。要确认 TUI 中实际选中的模型，需要登录后启动交互界面查看。
上下文长度两套口径：CLI 目录中的 context_window 与 API 模型页的 context window 不是同一个数。做成本估算或设计长上下文流程时，不要直接套用 API 页面的数值。超过 272K 输入时的计费倍率与 CLI 的实际处理方式，请以官网当前信息为准。
推理强度默认值可能随模型变化：gpt-6.1-sol 的 default_reasoning 为 low，gpt-6-sol 为 medium。若升级后感觉响应风格变化，除模型外也应检查推理强度设置。
Daybreak 的启用写法：只认 --enable cli_daybreak 或 features.cli_daybreak=true，daybreak=true 无效。自动 Cyber 路由还需要特定的登录与 provider 组合。
显式覆盖仍受兼容性检查约束：0.162.1 之后，后台服务端与 CLI 的功能设置差异本身不再导致启动失败，但显式覆盖功能设置时仍会检查兼容性。使用 --enable 启动时，注意两侧设置是否一致。
已移除的子命令：codex mcp-server 已弃用并移除，旧流程需要单独迁移。
易变信息：模型可用方案、退役时间、价格与计费倍率等均可能调整，使用前请以官网当前信息为准。