Codex 特性开关的五个阶段：removed 不等于功能没了

2026-08-09

第一次翻 codex features list 的输出，多数人会被中间那一列绊一下。它不是 on/off，而是一个阶段标签，取值有五种：stable、under development、experimental、deprecated、removed。更让人困惑的是，标着 removed 的特性居然还在列表里躺着，有的生效值还是 true。

Codex（OpenAI Codex）的这套阶段标注其实是一个很实用的决策信号——它回答的不是”这个功能存不存在”，而是”这个开关值不值得你去动”。下面把五个阶段拆开，顺带说清那些容易读反的地方。

先看清这张表有三列，别把第二列当成开关

在 codex-cli 0.147.0（Windows 11）上执行：

codex features list

输出是三列：特性名、阶段、当前生效值。官方对 codex features 三个子命令的说明也很直白：list 列出已知特性、所处阶段与当前生效状态，enable 和 disable 则是把结果写进 config.toml。

关键点在于，阶段和生效值是两条独立的信息。阶段说的是这个开关在产品生命周期里的位置，生效值说的是你这台机器此刻的实际状态。把两者混着读，就会得出”stable 的一定开着""removed 的一定关着”这类错误结论——本机实测里这两条都被打脸了。

五个阶段分别意味着什么

下面这几行是在 codex-cli 0.147.0（Windows 11）上实际观测到的，特性阶段会随版本变动，别把它当成长期结论，你自己那台机器该跑一次 codex features list 看当次输出：

特性	阶段	生效值
`hooks`	stable	true
`memories`	stable	false
`unified_exec`	stable	false
`network_proxy`	experimental	false
`prevent_idle_sleep`	experimental	false
`code_mode`	under development	false
`token_budget`	under development	false
`use_legacy_landlock`	deprecated	false
`web_search_cached`	deprecated	false
`apply_patch_freeform`	removed	false
`steer`	removed	true
`undo`	removed	false

stable：功能已经定型，可以放心写进团队的共享配置里。但”稳定”不代表”默认开着”，见下一节。

under development：正在做，还没做完。code_mode、token_budget、standalone_web_search 在本机都是这个阶段，生效值都是 false。这一档的处理建议很简单——别把它放进任何有人依赖的工作流。你今天手动打开它跑通了，明天升个版本行为可能就变了，而升版本这件事在 Codex 上是会自己发生的（check_for_update_on_startup 默认 true）。

experimental：可以试，但要有心理准备。network_proxy 在配置文件里既能写成布尔值也能写成一张表，表里有一堆网络策略键——功能不算简陋，可它带着 experimental（实验性）标签，意味着键名和行为都还没有稳定承诺。要用就在个人机器上用，别下发给全组。

deprecated：功能还在，但这个开关已经不是正确的入口了。最典型的一组是 features.web_search、features.web_search_cached、features.web_search_request，官方明确标注这三个键均已弃用，改用顶层的 web_search 键。这里的判断依据很清楚：看到 deprecated，你要找的不是”怎么打开它”，而是”官方把入口挪到哪去了”。顺带说一句，顶层 web_search 的默认值是 cached，可选 disabled / cached / indexed / live——默认既不是关闭也不是实时，这一点在排查”为什么它搜到的东西不新”时经常用得上。

removed：这一档是本文标题里那句话的来源。

removed 不等于功能没了

本机实测里，steer 的阶段是 removed，生效值却是 true；sqlite、item_ids 也是同样的组合。如果 removed 意味着”功能被删掉”，一个被删掉的功能不可能生效值为 true。

合理的读法是：removed 指的是”这个开关本身不再需要你控制”，对应的行为已经固化进产品，而不是行为消失了。所以看到 removed 项：

生效值是 true：这个行为现在是默认行为的一部分，你不用管，也基本没法通过这个开关关掉它。
生效值是 false：这条路径不再由这个开关驱动，别再去搜”怎么把 apply_patch_freeform 打开”，那是在追一个已经不接线的开关。

要提醒一句，features list 这份输出只给了阶段和生效值两个信息，它没有告诉你每个 removed 特性具体是怎么固化的。所以别在这上面往下推断”所以现在改文件一定走某某机制”——那部分不在这份输出的射程内，需要另找官方说明。

阶段标签和生效值的三种错位

这三种错位是真实会咬人的地方，都能在本机实测里找到对应：

错位一：stable 但默认关闭。 memories 在 0.147.0 上阶段是 stable，生效值 false；官方配置文档里 features.memories 的默认值也写的是 false。稳定和默认开启是两回事，想用就得自己开。

错位二：平台差异导致生效值和文档默认值不一样。 官方给 features.unified_exec 标的默认值是 true，但后面跟了一句”Windows 除外”。本机是 Windows 机器，codex features list 实测这一项生效值就是 false。两边是对得上的——但如果你只看了文档那张默认值表，就会在 Windows 上白白排查半天。跨平台抄配置之前，先在目标平台上跑一次 features list。

错位三：removed 但值为 true。 前面已经说过，不重复。

顺着这三条，判断逻辑可以收成一句：文档告诉你默认值，features list 告诉你实际值，两者不一致时以后者为准，然后去找是平台、配置还是阶段变动造成的差异。

开关写在哪：三种写法对应三种意图

同一个特性有三种打开方式，选哪种取决于你打算让它活多久。

只在这一次会话里试试，用顶层选项，可重复：

codex --enable <FEATURE> --disable <OTHER_FEATURE>

官方说明写得很明确：--enable <FEATURE> / --disable <FEATURE> 等价于 -c features.<name>=true / =false。所以下面这条是同一件事：

codex -c features.memories=true

-c 的两个细节值得记住：点号路径表示嵌套（foo.bar.baz），value 按 TOML 解析，解析失败则按字面字符串处理——这条很坑，写错了不一定报错，可能被当成字符串悄悄吞掉。

想让它长期生效，用子命令，它会写进 config.toml：

codex features enable <FEATURE>
codex features disable <FEATURE>

想手写配置文件，就在 ~/.codex/config.toml 里写：

[features]
memories = true

[features.code_mode]
enabled = false

以上为按官方文档键位组合的示例，未逐项实测，以官方文档为准。注意 code_mode 在官方配置文档里的键是 features.code_mode.enabled（under development 阶段），和 features.memories 这种直接给布尔值的写法不是一个形状——不是所有特性键都长一样。

选择上的判断依据：under development 和 experimental 阶段的东西，优先用命令行的 --enable 临时试，别急着写进 config.toml。写进配置文件意味着它会跟着你所有会话跑，而这两个阶段的行为没有稳定承诺。

改完之后怎么验收

改配置最怕的是”改了没生效还以为生效了”。两步验收：

第一步，跑 codex features list 看那一列生效值有没有变。 这是最直接的确认，比翻配置文件靠谱，因为它给的是解析之后的实际状态。

第二步，跑 doctor 确认配置真的被加载了：

codex doctor --summary

在 codex-cli 0.147.0（Windows 11）上实测过一个很有说服力的场景：故意用 -c 传一段语法不合法的 TOML，命令并没有崩溃退出，doctor 照常跑完，但结果里多了一行：

✗ config       config could not be loaded - Fix the reported config error, then rerun codex doctor.

这说明配置坏掉的时候 Codex 不一定报错给你看，但 doctor 会明确告诉你配置没加载成功。所以”我改了开关怎么没反应”的第一步排查，就是看 doctor 输出里的 config 这一行。顺带一提，codex doctor --json 官方说明是输出脱敏报告，要贴给别人看的话用这个。

至于 --strict-config，它的定位是：config.toml 里出现本版本不认识的字段时直接报错退出。听起来像是拼写错误的保险，但它有边界——本机实测把一个拼错的键配上 --strict-config 去跑 exec --help，help 正常打印，没有报未知字段错误。说明校验发生在真正加载配置进入会话的路径上，--help 这类不进会话的命令不触发。别把它当成”任何情况下都能拦住拼写错误”的护栏。

什么时候别折腾这些开关

三种情况建议直接收手：

一是你要解决的问题本身不在开关层面。阶段标签解释的是开关的生命周期，不解释功能行为本身。

二是你想按别人的博客或配置片段照抄。特性阶段和生效值都随版本走，本机这份观测是 0.147.0 的快照，而 Codex 自己就会更新——同一台机器上，本次采集开头 codex --version 还是 codex-cli 0.131.0，十几分钟后再执行就变成了 codex-cli 0.147.0。抄之前先在自己机器上跑 codex features list 和 codex --version。

三是你在给团队下发配置。团队配置里只放 stable 阶段的键；deprecated 的换成官方指定的新入口；under development 和 experimental 的留给个人机器。