Codex CLI 0.164.0：十个提示词槽位，把每天重复说的话收进工具里

先说结论：这是一次“把重复劳动收进工具里”的版本

Codex CLI 0.164.0 在 2026 年 10 月 23 日发布，没有新模型、没有新计费档位、也没有改写 agent 架构的宏大叙事。它的主角是三件小事：十个可复用的提示词槽位（/presets）、可以直接在命令里写清模型与权限的内联参数（/model 与 /permissions），以及更难丢的会话恢复。听起来不刺激，但对每天在终端里和 agent 打交道的人来说，这三件小事恰恰是那种“每天省五分钟、一个月省两小时”的改进——而且它们解决的问题不是模型不够聪明，而是人每天都在重复说同一句话、重复设同一个开关、重复为一次失败的压缩丢掉上下文。

判断一个 CLI 版本值不值得升，不要只看功能列表的长度，要看它动的是哪一层。0.164 动的是“操作层”：提示词、模型选择、权限配置、会话恢复、凭证遮蔽、磁盘占用。操作层的改进有一个特点——它们不会出现在基准测试榜单上，却会出现在你每天的工作流里。这篇文章就按这个标准来拆：哪些改动值得你今天就用起来，哪些只是顺手修掉的边角，以及升级时要注意什么。

新闻事实：10 月 23 日发布，GitHub Release 与官方 Changelog 一致

OpenAI 的 Codex CLI 0.164.0（Rust 版本号 rust-v0.164.0）于 2026 年 10 月 23 日发布，安装命令仍是 npm install -g @openai/codex@0.164.0。GitHub Release 页列出的新功能与 OpenAI 官方 Changelog（ChatGPT Learn 的 Codex changelog）逐条一致：十个编号的 /presets 槽位、内联的 /model 与 /permissions 参数、Kitty 或 Sixel 终端里的全屏转录图片预览、企业 MCP 连接的认证方式、远程 Bash 与 Zsh 快照会话里的凭证遮蔽，以及默认开启的 Amazon Bedrock 设置向导。

修复清单同样值得读一遍，因为其中有两条直接关系到“会话会不会丢东西”：失败的压缩（compaction）不再往对话历史里留下半截摘要，后台压缩失败时不再惊慌失措式地崩溃；恢复会话时，系统会找到已压缩的历史并恢复保存的线程设置，而不是用全局默认值把它覆盖掉。另外还有 Windows 代理认证、命令行多层 -c 配置覆盖保留、排队提示词等待权限选择完成、macOS 大小写变体元数据路径与可替换符号链接的沙箱加固，以及通过清理未使用的安装、废弃的市场检出和限制守护进程日志来减少磁盘占用。这些修复没有一条是 headline，但合起来讲的是同一件事：让长时间、高频使用的 CLI 更难在边缘情况下丢状态、漏凭证、胀磁盘。

需要提醒一句：0.164.0 不是一次“必须立刻升”的安全更新，也不是一次“升了就回不去”的架构迁移。它是一次常规的功能与修复合集，升级成本低、回退也容易。真正需要你花时间的不是升级本身，而是升级之后要不要把 /presets 用起来——因为那涉及到你个人的工作习惯，而不是工具的版本号。

/presets：十个槽位，解决的是“同一句话说十遍”

/presets 的设计非常克制：十个编号槽位，可以保存可复用的提示词和斜杠命令，附带一个键盘菜单方便快速调用。没有模板变量系统，没有跨设备同步的宏大承诺，没有“提示词市场”——就是十个格子，你把常用的指令放进去，用的时候按编号调出来。这种克制恰恰是它的优点：学习成本几乎为零，失败模式也几乎为零。

哪些提示词值得放进槽位？我的标准是三条：第一，每周至少用两次；第二，每次手写都容易漏掉关键约束（比如“只改这三个文件”“不要动测试快照”“先跑测试再提交”）；第三，出错代价高（比如涉及数据库迁移、发布流程、权限变更）。符合这三条的典型例子：固定的代码审查提示词、固定的重构检查清单、固定的发布前检查、固定的故障排查开场白。反过来，只用一次的长提示词不值得进槽位——放进去也是占着格子吃灰，找的时候还得多翻一页。

还有一个容易被忽视的组合：/presets 加上 10 月 24 日 Codex 方面的另一条跟进——会话中切换推理级别不再使提示词缓存失效。两件事合起来，才构成一个真正可用的“便宜推理做默认、贵推理按需上”的工作流：平时用低推理级别快速改小东西，遇到难题时切到高推理级别，不用为整段对话重新付费。单独看任何一条，都只是小改进；合起来看，它们在把“按任务调推理级别”从一句口号变成一个可以每天执行的操作。

使用建议上，我主张给槽位编号定一个个人约定，而不是随手乱放。比如 1 号永远是代码审查，2 号永远是测试与修复，3 号永远是发布检查——编号固定下来，肌肉记忆才能形成；否则每次用之前还要先想“审查是几号来着”，省下的时间又花在了回忆上。团队里如果多人共用一台机器或共享配置，更要把编号约定写进团队文档，避免你的 1 号和别人的 1 号是完全不同的东西。

内联 /model 与 /permissions：把“这次用什么配置”写进同一行

0.164 的第二组改动是内联参数：/model 可以直接带上模型、推理强度、速度；/permissions 可以直接带上权限配置。以前切换这些要么进设置、要么多走几步交互，现在可以在发出任务的同一行里写清“这次用哪个模型、多大推理力度、什么权限”。这对两种人特别有用：一种是在同一会话里频繁切换配置的人（比如先低推理快速探路，再高推理攻坚）；另一种是把操作写进脚本或团队手册的人——配置从“口头约定”变成了“命令里可见的参数”，复现和交接都更容易。

权限配置值得单独说一句。0.164 还允许把当前的权限设置保存为 preset，这意味着“这套权限配置”本身也可以复用。对团队来说，这比口头说“记得把权限设成某某模式”可靠得多：新成员照着 preset 走，不会因为漏设一个开关就让 agent 在不该动的地方动了手。但也要提醒：preset 里保存的是配置，不是审批——把高权限配置存成 preset 不等于给它背书，每次调用高权限 preset 之前，仍然要确认这次任务真的需要这个权限级别。工具把“设权限”变容易了，并没有把“判断权限合不合适”也变容易。

企业侧还有一条相关改动：企业 MCP 连接现在可以通过符合条件的 Codex 账户授权或专用登录来认证，包括需要密钥的 OAuth 客户端。这条改动的目标用户很明确——在企业环境里用 MCP 的团队。个人用户可以忽略它，但企业管理员应该把它和凭证遮蔽那条放在一起读：0.164 在“企业连接怎么登”和“远程命令里凭证怎么藏”两端同时收紧，这是一个连贯的安全收紧方向，而不是两条孤立的修复。

会话恢复与凭证遮蔽：修的是“丢东西”和“漏东西”

会话恢复的两条修复值得所有重度用户注意。第一，失败的压缩不再留下半截摘要。压缩是长会话的生命线：对话太长时把它压成摘要，才能继续聊；如果压缩失败还留下一段残缺的摘要，后续对话就建立在一份损坏的记忆之上，表现就是 agent 突然“忘了”前面说好的事，或者把半截摘要当成事实来引用。0.164 把这个口子堵上了：失败就是失败，不留半截货。

第二，恢复会话时保存的线程设置会被找回来，而不是被全局默认值覆盖。以前的毛病是：你给某个线程设了特定的模型、权限或推理级别，恢复之后却发现全被重置成默认值，还得重新设一遍——而且往往是在已经发了几条消息之后才发现，前面几条消息已经按错误的配置跑了。这条修复把“恢复”从“大概恢复”变成了“真正恢复”，对长期维护同一个项目的用户尤其重要：项目线程的配置就是项目的工作约定，丢了它等于丢了上下文的一半。

凭证遮蔽则是另一条安全线：远程 Bash 命令和 Zsh 快照会话里，来自自定义供应商的凭证也会被遮蔽。这类问题平时看不见，出事时就是大事——一次终端输出被粘贴到 issue、聊天记录或日志里，凭证就跟着出去了。0.164 的做法是在输出层面做遮蔽，而不是指望用户每次都记得手动打码。我的建议是：即使升级了，也不要把“输出会被遮蔽”当成可以随意粘贴终端输出的理由；遮蔽是最后一道防线，不是第一道。真正安全的做法仍然是：敏感输出不进公共频道，凭证定期轮换，遮蔽只是兜底。

磁盘与沙箱：不起眼，但决定了 CLI 能不能长期用下去

0.164 还做了两组“基础设施卫生”工作。磁盘方面：清理未使用的安装、废弃的市场检出、限制守护进程日志——这些改动不会让你今天快多少，但会让三个月后的 CLI 不至于因为日志和旧安装把磁盘吃满。长期高频使用 CLI 的用户都遇到过类似问题：工具越用越慢，最后发现是某个角落的缓存或日志在悄悄膨胀。0.164 在这个方向上迈了一步，但用户自己也该定期跑一下清理命令、看一眼磁盘占用，不能全指望工具自觉。

沙箱方面：加固了 macOS 上大小写变体元数据路径的检查，以及用于定位可执行文件的可替换符号链接的检查。这类加固的共同点是“攻击者利用的是你以为不存在的歧义”：文件系统对大小写不敏感时，两个看起来不同的路径可能指向同一个文件；符号链接被替换时，你以为在执行 A，实际执行的是 B。沙箱的价值就在于把这些歧义提前堵住。普通用户不需要理解每个加固的细节，但需要理解结论：沙箱不是摆设，每次它拦住一次操作，背后都可能是一次真实的歧义利用；不要为了图方便就把沙箱关掉。

Windows 用户还有两条专属修复：HTTPS 与 WebSocket 连接现在会用登录用户的 Negotiate 或 NTLM 凭证处理代理认证挑战；命令行多层 -c 配置覆盖也会被保留。在企业网络里用 Codex CLI 的 Windows 用户，这两条可能比 /presets 更先被感知到——因为代理认证失败是那种“一上来就卡住”的问题，修好了就是从“用不了”到“能用了”的区别。

升级建议：升，但把时间花在整理槽位上

我的升级建议很简单：升到 0.164.0，成本低、收益明确。升级后先做三件事。第一，挑出你每周至少用两次、且每次手写都容易漏约束的提示词，放进 /presets，并给编号定一个固定约定。第二，检查你长期维护的项目线程：恢复一次，确认模型、权限、推理级别这些线程设置是不是真的回来了——如果以前被默认值覆盖过，这次可以验证修复是否生效。第三，看一眼磁盘占用和日志大小，确认清理机制在工作。

不建议做的事也有三件。第一，不要因为有了 /presets 就把所有提示词都塞进去——十个槽位是让你挑最常用的，不是让你建一个提示词仓库；塞满之后找起来更慢，得不偿失。第二，不要把高权限配置存成 preset 后就不再复核——preset 省的是设置时间，不是判断时间。第三，不要把这次升级当成“模型升级”来宣传给团队——0.164 没有新模型，团队如果冲着模型能力来升级，会失望；冲着操作效率来升级，才会满意。

给团队的落地清单：从个人习惯到团队约定

个人升级只需要一条命令，团队落地却需要一份约定。第一，把 /presets 的编号约定写下来：比如全团队统一 1 号是代码审查、2 号是测试修复、3 号是发布检查，新人入职第一天就能照着用，而不是每个人从零摸索自己的编号。第二，把常用 preset 的内容放进团队仓库的文档里，接受评审——提示词也是代码，值得被 review；一个写错了约束的审查提示词，会在全团队范围内系统性地漏掉同一类问题，比一个人手写错一次的危害大得多。第三，定期回顾槽位的使用情况：连续一个月没被调用的槽位就该腾出来，换成真正高频的指令；槽位是稀缺资源，不是收藏夹。

权限 preset 同样需要团队约定。建议给权限 preset 分级：日常级、发布级、危险级。日常级可以随便用，发布级需要二次确认，危险级（比如能删数据、能改生产配置）原则上不进 preset，或者进了也要在名称里明确标注“危险”，并且每次调用前口头或书面确认一次任务范围。工具不会替你做分级，分级是你自己的管理制度，preset 只是让制度更容易执行，而不是代替制度。

最后是会话与日志的习惯。长期项目建议一个项目一个线程，线程设置就是该项目的工作约定；定期检查线程恢复是否正常，定期清理磁盘占用，定期检查终端输出里有没有不该出现的凭证信息。这些习惯听起来琐碎，但它们正是区分“用 agent 干活”和“被 agent 拖着走”的分界线：前者把工具纳入自己的工作系统，后者只是把任务扔给工具、然后为工具的每一次意外买单。0.164 给了你更好的工具，工作系统还得你自己搭。

最后说一句判断：Codex CLI 正在从“能用的 agent 终端”走向“每天离不开的工作台”，而工作台的进化从来不是靠一次大发布，而是靠 /presets 这种把重复劳动收进工具里的小步快跑。0.164 就是这样一步：不大，但每天都能感觉到。如果你每天都在终端里和 Codex 打交道，升上去，把槽位整理好，然后继续干活——这就是这个版本最正确的使用方式。

补充一个升级后的检查习惯：每周花五分钟回顾一次槽位调用情况，把连续两周没用过的槽位换掉，把新出现的高频指令补进来；工具的配置和代码一样需要定期整理，放任不管的配置迟早会变成新的重复劳动。