你让 Codex 重构认证模块，跨 40 个文件。四十秒之后你发现方向错了：它在按 session 方案往下写，而你要的是 JWT token。

这时候你敲一行新指令进去，会发生什么？

在默认配置下，什么都不会发生。Codex 会先把手上这次工具调用跑完，可能是一条几秒的 shell 命令，也可能是一串连续的文件写入，等它回到输入缓冲区，才看得到你刚才那句话。等你这行字生效，session 方案已经铺进十几个文件了。

Codex CLI 给这个行为留了一个开关：instant_interrupt。打开它，你的输入会立刻中断当前工具调用，控制权马上回到你手里。

一行配置的事，但它动的是交互模型的底层。

为什么默认要等#

根源在同步执行。Codex 发起一次工具调用，然后阻塞，直到这次调用结束，再回头重新评估交互状态。

同步的好处是可预测。每一步都是完整的原子操作：工具调用跑完，结果进上下文，模型生成下一步。步骤和步骤之间，状态永远干净一致。

坏处是不听话。它在干活的时候你按键，它听不见。

打开 instant_interrupt 之后，新输入（一行改方向的指令、一次按键、一个 Ctrl+C）会立即打断当前工具调用。它不等 shell 进程退出，不等文件写完，不等网络请求返回。

怎么打开#

~/.codex/config.json 里加一行：

{
  "instant_interrupt": true
}

或者写成 TOML：

instant_interrupt = true

几个需要知道的设定：

  • 默认是 false，到现在仍然是 opt-in
  • 没有对应的命令行参数，只能在配置文件里设
  • 设定对这台机器上所有 Codex 会话生效，目前没有按会话或按项目的覆盖方式

有它和没它，差在哪儿#

没开 instant_interrupt 的时候：

你：       [发送改方向的指令]
Codex：    [跑完当前工具调用，可能 2 到 30 秒]
Codex：    [读到你的指令]
Codex：    [按新方向开始执行]

打开之后：

你：       [发送改方向的指令]
Codex：    [立刻停掉当前工具调用]
Codex：    [读到你的指令]
Codex：    [按新方向开始执行]

差别就是中间那一行，也就是你等了多久才把控制权拿回来。

三个真正用得上它的场合#

重构到一半发现方向错。 让它重构认证模块，四十秒后你意识到它在搭 session 认证，而你要 token 认证。敲一句「停，用 JWT token 认证，不要 session」，重构就停在下个自然断点。没这个开关，你只能眼看着 session 方案再铺一分钟。

错误模式还没扩散。 Codex 在生成测试，选了 unittest 风格，你的项目用 pytest。你在第一个文件之后就发现了。有这个开关，改方向的指令会在二十个测试文件被写出来之前生效。没有它，你就得回滚二十个文件。

危险命令正在跑。 它在执行一条你后知后觉发现是破坏性的 shell 命令，大范围的 git clean、一句 DROP TABLE、一次你没打算做的递归删除。这是最重要的用例，也正因为这个用例，它必须是 opt-in：中断会带来一类新的状态，工具调用被砍在一半。

代价：半成品状态#

把一个工具调用停在执行中，产生的状态既不是「完成」，也不是「干净地没有」。

  • 文件写到一半被打断，留下一个残缺文件
  • 多步骤 shell 管线断在中间，系统停在某个说不清的中间态
  • 网络请求发出去了、还没收到响应就被打断，远端状态未知

这不是假想的风险，发布说明里专门写了这条注意事项。下面几种用法相对安全。

读密集型会话可以放心开。 分析、代码审查、搜索、规划这类任务中断了不留后遗症，读文件、查代码库没有持久副作用。写密集型会话风险高得多。

和沙箱一起用。 Codex 跑在沙箱里（sandboxPolicy: read-only，或配置里的 sandbox: true）时，被打断的写入不会落盘，沙箱会把那半成品丢掉。这是生产环境里推荐的组合。

发指令之前先看一眼打断点。 TUI 状态栏会显示当前工具调用。如果它正在写文件，或者正在跑一条有副作用的 shell 命令，先想清楚现在打断安不安全。不安全就等它跑完。

被打断过的会话，收工前查一下 git status。 半截的文件写入会以「已修改」的形式出现在 git 里，提交之前跑一次 git diff，确认暂存区里没有损坏的文件。

instant_interrupt 和 fork：改方向，还是留着看#

Codex CLI 有两个会话中途的控制手段，另一个是 fork，在 TUI 里按 f 触发。它们解决的是两个不同的问题。

对比项instant_interruptfork
做什么停掉当前执行并改方向从当前状态分出一个并行分支
保留原分支不保留保留
什么时候用当前方向本身就是错的想试另一种做法，又不想丢掉已完成的进度
会话成本原会话继续新会话，新的上下文成本
怎么触发敲新指令或 Ctrl+C按 f

一个实用的分界线：任务已经做到八成，剩下两成想换个做法，用 fork，保住做完的部分，两条分支还能对比。方向从一开始就错了、整条路都不想要，那就用 instant_interrupt 加一句改方向的指令。

两者可以配合：先用 interrupt 掐掉错的分支，再在修正后的状态上 fork，把两个实现方案并行跑出来比。

/agents 面板里的打断#

/agents 面板把所有正在跑的 Codex agent 收进一个 TUI 面板，每一项带状态（running、waiting、complete、error）、当前工具调用，以及包括打断在内的操作按钮。

有意思的地方在这儿：instant_interrupt 没开的时候，你在面板上按打断，这个信号同样要等当前工具调用跑完才生效。一条慢 shell 命令，你按下按钮，十到三十秒之后才真的停下来。

/agents 加 instant_interrupt，才是那个多 agent 操控界面的完整形态：一个面板盯着五个并行 agent，哪个方向偏了就立刻掐掉，再补一句新指令让它继续。DevDay 2026 演示的就是这套流程。

┌──────────────────────────────────────────────────────────┐
│ [running]  agent-1 写入: src/auth/token.ts                │
│ [running]  agent-2 执行: npm test -- --watch              │
│ [waiting]  agent-3 等待用户批准                            │
│ [running]  agent-4 读取: docs/api-reference.md            │
│ [complete] agent-5 完成: 更新了 12 个测试夹具              │
└──────────────────────────────────────────────────────────┘
按 [i] 立即打断选中的 agent（需要 instant_interrupt: true）
按 [f] 把选中的 agent 分叉成新分支

什么时候别开#

有几类场景应该老实留在默认的 false。

CI 和自动化。 键盘前面没有人的地方，这个开关不该存在。CI 日志查看器里的一次误触、一个跑飞的进程，都不应该把发布流水线掐停在中间。这是个人在环的特性，全自动场景里它只带来风险。

没有沙箱的写密集型任务。 大批量生成文件（整套测试、一个文档站、一份迁移脚本），中断后文件会停在前后不一致的状态。跑不了沙箱又需要大量写入的时候，默认的同步模型更安全。

非交互式终端环境。 跑在 screen 里、多人共用的 tmux 面板里，按键拦截本身不可靠。切换面板时的杂散按键就可能触发一次意外打断。

带外部副作用的任务。 调外部 API、发邮件、写数据库、改共享基础设施，中断后远端状态会不一致，比本地写坏一个文件难收拾得多。

一条经验规则：交互式工作、任务主要发生在本地，就开；任务是自动化的，或者会碰那些被中断后很难恢复的系统，就别开。

一个容易被忽略的信号#

同一批发布里还删掉了一个东西：「后续提问建议」，也就是每次回答之后 TUI 给出的那些提示，告诉你接下来可以问什么。删它和加 instant_interrupt 是同一轮的事。

两个改动方向相反，放在一起看就是一条产品信号。后续建议是扶着新人走的扶手，它替经验不足的用户猜下一步。instant_interrupt 是给老手的控制器，它假设你知道自己要什么，并且能在会话中途下出精确的指令。同一个版本里加一个、删一个，说的是 Codex CLI 要服务的对象变了：是那些精确操控 agent 的熟练工，不是需要别人告诉下一步做什么的新手。

放进 DevDay 2026 整批发布里看就更清楚。/agents 是给高阶用户的监控界面；GPT-6.1 Sol 成为默认模型，改变的是跑很多并行 agent 的团队的成本假设；instant_interrupt 给这些 agent 补上了之前没有的操控手段。这一批改动面向的是规模化使用 Codex 的团队，不是偶尔跑一次的个人。

需要说明的是，不同来源对这几个特性落在哪个版本号上说法并不一致，instant_interrupt 有文章记作 v0.159.0，也有的记作 v0.162.0，/agents 面板同样存在 v0.156.0 和 v0.159.0 两种说法。要看准确版本，以官方 changelog 为准。

对架构的影响#

instant_interrupt 不只是一个交互上的便利，它改的是执行模型，会影响你长会话怎么设计。

同步模型里每一步都是原子的：工具调用完成、结果进上下文、模型生成下一步，步骤边界上状态总是干净的。打开这个开关之后，从用户角度看工具调用不再原子，你可以比步骤边界更细地去观察和干预。

几个具体推论：

打断时刻的上下文未必在干净的边界上。 模型当时执行到一半，你的新指令被注入进一个含有残缺工具结果或截断工具调用的上下文。多数情况下 Codex 处理得了，但复杂的工具调用序列（多步 shell 管线、嵌套文件操作）在特定位置被打断，可能给出意外行为。

长会话需要检查点纪律。 如果你打算在会话里频繁用它，把会话按显式检查点切段，比如「先把分析做完，我确认了再开始写」，能减少在麻烦的位置打断的概率。/ask 审批策略是互补的：它在写入前暂停，天然给了你一个不需要 instant_interrupt 的决策点。

给 Codex 写外围工具的人要注意。 如果你的脚本或编排层会轮询 Codex 任务的完成信号，这个开关改变的是你可以做的假设：原来可靠且原子的工具调用，现在可以被中断。任何轮询完成状态的代码都得显式处理被打断的状态。

小结#

instant_interrupt 是一行 opt-in 配置，把 Codex CLI 从同步的请求-响应模式，变成一个可以被操控的交互式进程。收益很直接：不用等这次工具调用跑完就能改方向。风险得你自己扛：被打断的工具调用会留下半成品状态。

交互式、主要在本地、读多写少，就开。CI、自动化、没有沙箱保护的写密集型任务，就关着。配合 fork 用，把「这个方向错了」和「两个方案我都想看看」区分开。

instant_interrupt、/agents、fork 凑在一起，是 Codex CLI 第一套完整的会话中途操控手段。搞清它们各自管什么，是从「一次小心地跑一个 agent」走到「有把握地同时跑五个 agent」之间那道坎。

参考来源：instant_interrupt: How Codex’s New Steering Mode Changes the Execution Model，Daniel Vaughan，Codex Knowledge Base，2026-10-12。