OpenAI Codex 0.159.0 将运行中引导推向核心位置
OpenAI Codex 0.159.0 引入了一种选择启用的方式，可在活跃智能体完成当前回复或长时间运行的命令之前改变其方向。这听起来像是一项狭窄的界面改动，实际却瞄准了智能体编程中最棘手的问题之一：在不丢弃有价值工作的前提下，纠正错误方向。
该版本于 2026 年 9 月 29 日发布，包含六组功能和大量修复。其核心新增功能 instant_interrupt 可让新的输入抢占模型回复，并使某些代码模式调用提前让出控制权。代码模式是 Codex 用于运行命令并等待持续进程的执行路径。
这让 Codex 直接加入与 GitHub Copilot CLI 及其他编程智能体的交互竞赛。竞争不再仅限于哪个模型能写出最强的补丁，也越来越关乎哪个智能体能在真实工作进行时保持可理解、可引导且可恢复。
OpenAI Codex 0.159.0 实际改变了什么
该版本将智能体控制视为持续交互，而非一连串彼此孤立的提示。
完整的 Codex release 以 instant_interrupt 为中心，不过该标志默认仍处于禁用状态。启用后，新的用户输入可以在模型回复过程中引导 Codex，也会影响长时间运行的代码模式 exec 和 wait 调用。
此前，在这些调用期间提交的输入可能会一直排队，直到调用返回。这种行为可预测，但当用户发现错误假设时，会带来高昂延迟。智能体可能在读取纠正信息前继续测试、生成输出，或沿着错误的实现路径推进。
新机制会在每次采样请求期间监视排队输入，随后向符合条件的工具调用传递共享的抢占信号。正在运行的单元可以在不被终止的情况下让出其标识符，使 Codex 能够处理新指令。
这一差异很重要。让出控制权并不等同于终止命令。底层工作可以继续进行，而后续的 wait 调用仍可收集其结果。Codex 因而获得重新考虑下一步行动的机会，同时不会自动破坏仍有价值的执行状态。
配套的模型回复改动则完成了这一闭环。新的输入可以抢占正在生成的回复，而非排在其后等待。该版本还会在中断路径中保留排队消息和工具结果。
设想一位开发者要求 Codex 重构认证服务。智能体运行测试时，开发者发现旧客户端仍依赖现有令牌格式。启用即时中断后，这一约束可在 Codex 完成原计划前传达给它。
该版本还包含多项呼应同一主题的小型界面改动。新会话显示更紧凑的欢迎页面，并采用一致、无边框的标题。提示可在活跃工作期间及一轮操作结束后显示。
警告查看器现在会在关闭时忽略用户此前已查看的警告。按下 k 可保留选中的警告以便稍后处理。这使查看器成为轻量级分流队列，而非要求反复检查的列表。
用户还可在计划实施对话框保持打开时滚动查看记录。这支持一种基础但重要的审查模式：在授权拟议改动之前，重新阅读证据。
这些 Codex 0.159.0 功能共同降低了长时间智能体会话周边的界面摩擦。该版本并未发布新的编程模型，而是改变了人类能够多快影响已在工作的模型。
即时中断改变了纠正的成本
运行中引导之所以重要，是因为早期纠正通常比审查已经完成的错误更便宜。
编程智能体不会从提示直接走向完成的补丁。它会检查文件、形成计划、调用工具、读取结果、修改代码并验证这些改动。一个错误前提可能扩散到每一个阶段。
传统聊天界面会把新消息置于当前回复之后。这样的排序适合答案简短的问题；但当智能体运行耗时数分钟的命令，或等待完成时间不确定的进程时，就会显得限制颇多。
OpenAI 的 yielding implementation 解决了这一延迟，同时并未假设每条新消息都应取消当前工作。活跃单元会让出控制权，但仍继续运行。Codex 随后可纳入新指令，并决定如何推进。
这在等待与中止之间创造了一个中间地带。等待能保留工作，却延迟纠正；中止能立即响应，却可能浪费执行进度，或让用户不清楚究竟停止了什么。
Codex 的即时中断设计旨在同时保留响应性与连续性。这是该版本的核心机制，也比新增一个快捷键或视觉刷新更具意义。
该功能对涉及权限的工作也有影响。当智能体逐渐显露方向时，用户可以补充约束。例如，用户可禁止某项依赖、将编辑限制在一个包内，或要求向后兼容。
这种干预仍取决于时机。消息无法逆转已经发生的外部副作用，也不能替代对重要命令的审慎审批控制。
相反，即时中断缩短了识别问题与影响智能体之间的时间。随着编程任务变得更长、包含更多工具调用，这个更窄的窗口会愈发有价值。
其选择启用的状态值得关注。OpenAI 并未将这种行为作为通用默认设置。抢占会改变消息排序、执行时机和用户预期，因此谨慎部署是合理的。
用户还必须理解此处“中断”的含义。活跃的代码模式单元让出控制权后仍可继续运行。除非界面清晰传达单元状态，否则期待紧急停止的人可能误解这种行为。
response preemption change 涵盖了体验的另一部分。传入输入可以停止当前模型回复，并引导正在进行的回合。系统还会处理在上下文压缩期间到达的消息。
当对话规模变大时，压缩会总结较早的会话上下文。在这一过程中到达的输入必须被延后并保留，而非丢失或以不一致的顺序应用。
这些细节揭示了看似简单功能背后的难度。仅有一个响应迅速的文本框并不够。引导必须协调模型生成、排队输入、后台执行、工具结果和对话历史。
因此，OpenAI Codex 0.159.0 更像是一次编排更新，而非智能水平更新。它让智能体循环更易于中断，同时努力保留仍有价值的工作。
编程智能体的竞争不只在输出，也在控制
主要竞争正从自主完成转向执行过程中的有效协作。
GitHub 在其编程智能体产品中也记录了引导与排队之间的类似区别。引导消息会改变当前工作，而排队消息则等待下一回合。
在 GitHub Copilot 云端智能体会话中，后续引导会在当前工具调用完成后应用。GitHub 的 session controls 还提供实时进度、会话日志、停止和归档功能。
GitHub Copilot CLI 在本地界面中更进一步。智能体思考期间输入的普通消息默认会成为引导输入，用户也可另行将工作排队至后续回合。
OpenAI 的实现有一项重要差异：其选择启用的路径允许符合条件的长时间代码模式调用在底层进程结束前让出控制权。这可缩短用户干预与模型重新判断之间的延迟。
这并不能证明某款产品必然更快或更安全。该版本没有提供独立的延迟比较、完成度基准测试，或对减少无效工作的量化结果。任何更广泛的性能结论都为时过早。
但它展示了编程智能体竞争的方向。模型质量仍然重要，但实际差异化越来越来自对已经在进行中的工作的控制。
一个强大的智能体如果隐藏状态、延迟纠正，或迫使用户在全盘取消与继续之间二选一，仍可能令人沮丧。较弱的模型同样可能耗费大量时间，如果用户无法在错误扩散前重新引导它。
理想的交互更接近结对编程，而非任务队列。一方开始采取某种方法，另一方则可在证据出现时补充约束。双方都不必在每次纠正后重新启动整个任务。
这一模式也会影响企业评估。团队需要了解开发者能否检查活跃工作、理解待处理操作，并在智能体跨越项目边界前进行干预。
可审计性成为产品的一部分。补充上下文、改变方向、排队另一项任务和停止执行之间的区别也同样重要。这些操作不应看起来完全相同，因为其后果不同。
围绕警告、记录访问和会话呈现的改动支持了这一要求。它们让用户在决策仍未落定时获得更多信息，而非只看到已完成的结果。
这种交互模式也会奖励良好的项目上下文。当用户能提供由现有文档支持的精确约束时，引导效果最佳。searchable knowledge base 可帮助团队在批准智能体计划前检索这些约束。
OpenAI Codex 0.159.0 并未终结控制竞争，但确立了更清晰的产品方向：即使工具正忙，智能体也应保持响应。
小型功能让长会话更易阅读
这些界面改动降低了用户必须审查、批准或保留信息时的认知负担。
新的会话页面更紧凑，会话标题现采用一致的无边框设计。这些改动不会改变代码生成，但减少了终端界面中的视觉差异。
Codex 工作期间以及回合完成后，现在会偶尔显示提示。这可以在用户需要时呈现有用控制方式，尽管重复出现的指导必须避免成为新的噪音来源。
警告工作流获得了更实用的改动。关闭查看器会忽略用户已经审查过的警告。由 k 触发的保留并继续操作，可保留重要警告并推进选择。
这一设计将警告映射为熟悉的收件箱模式。已审查项目离开活跃队列，例外项则仍可使用。该改动应能减少在产生多条提示的会话中反复扫描的需要。
现在，当模态对话框询问 Codex 是否应执行计划时，转录内容仍可滚动浏览。此前，模态框可能恰恰在审阅最重要的时刻，限制用户回看先前讨论的能力。
批准计划并非一个仪式性的点击。要作出有价值的决定，可能需要核对原始请求、先前的工具输出、已识别的风险，以及代理所陈述的假设。能够访问转录内容，让这种比对更容易。
从转录内容复制文本也更加可靠。选区会保留 Markdown 表格、格式和重要的空白字符；此外，更多终端环境支持自动“选中即复制”行为。
当用户将生成内容转入问题追踪器、代码审查、文档或事故记录时，这项修复尤为重要。格式丢失可能改变日志、表格和代码相关文本的含义。
原生 Mermaid 渲染获得了更广泛的语法支持。Mermaid 是一种基于文本的图表语言，使用紧凑的源文本描述流程和关系。
更新后的渲染器能够保留标签中的标点和分号，也可识别更多流程图关系、边标签、方向标记和分组节点结构。
这让代理生成的架构图成为更实用的终端产物。开发者可以要求 Codex 解释服务流程，检查渲染结果，同时保留底层 Mermaid 源代码。
Mermaid 更新也凸显出一个反复出现的界面挑战：只有当渲染器接受模型通常生成的语法时，生成的图表才真正有用。
应用服务器客户端获得了一项更底层的能力：以项目为锚点的线程分页。客户端可相对于某个特定项目请求线程历史，而非只能通过更宽泛的页面进行导航。
这应有助于应用加载长对话中相关的部分，也让客户端开发者能更好地控制可恢复的时间线和增量历史视图。
这些新增功能都不具备即时中断那样的概念分量。但综合来看，它们让长时间会话更易进入、检查、导航和复用。
这很重要，因为随着对话增长，代理的可用性会下降。仅靠更好的模型，并不能解决转录导航、警告疲劳、图表渲染失败或格式丢失的问题。
Windows 与沙箱修复承担了实际运行层面的重任
此次发布还弥合了平台和安全层面的缺口，其重要性可能超过可见的界面改进。
在 Windows 上，Codex 现在会在启动多类子进程时抑制多余的控制台窗口。受影响的路径包括本地 Model Context Protocol 服务器、代码模式宿主，以及通过管道连接的命令。
MCP 是用于将模型连接到外部工具和数据源的协议。本地 MCP 服务器可能作为后台子进程运行，因此意外弹出的控制台窗口可能打断桌面端体验。
受限的 Windows 启动器现在可以回退到嵌入式模式。当进程创建规则阻止首选架构运行时，这提供了另一条执行路径。
此次发布还改进了残留 Windows 作业成员资格下的守护进程启动行为。另一项修复避免启动器的输入和输出句柄在不应附着时继续保持附着状态。
这些变更解决的是可靠性，而不是模型行为。它们尤其适用于受管理设备、桌面集成，以及会创建多个子进程的终端工作流。
安全边界也获得了单独关注。获批准的命令现在会保留明确的文件系统拒绝规则，而不再在命令准备过程中丢失这些限制。
当 .aws 目录位于可写根目录下时，Codex 默认也会保护它们。这些目录可能包含云配置或凭据，因此默认边界意义重大。
此次发布并未声称这些改动消除了沙箱风险。但它表明，OpenAI 正在收紧用户批准与执行时实际应用权限之间的衔接。
这一边界值得仔细审视，因为获批准的命令并不等同于不受限制的文件系统访问。如果准备命令时丢弃了明确拒绝规则，运行时就不再反映用户审阅过的决定。
启用网络的 macOS 沙箱获得了 TLS 信任修复。该更新允许相关 Seatbelt 配置文件进行系统信任评估；Seatbelt 是限制进程能力的 macOS 沙箱策略。
需要代理的远程环境也获得了修正后的执行行为。这些修复解决了开发工具名义上的网络访问能力与承载它的机器规则之间常见的落差。
认证也变得不那么脆弱。本地应用服务器流程应能更可靠地打开浏览器以进行 ChatGPT 登录。对于不适合自动打开的情况，引导流程现在提供了复制登录 URL 的快捷方式。
用户切换任务时，空白会话会保留草稿。线程可在包含首个已完成回合之前被归档和列出，使会话管理不再那么依赖对话状态。
这些修复强化了此次发布的整体方向。长期运行的代理不仅需要令人印象深刻的响应，也需要持久状态和可预测的进程行为。
一个会打开不必要窗口、丢失草稿、错误处理拒绝规则，或无法在代理后运行的编程代理，会带来运行成本。即使其生成的代码可以接受，这些故障也可能阻碍采用。
选择加入的引导仍需经受真实世界检验
这项功能的价值取决于可预测的时机、清晰的状态提示，以及压力下的正确行为。
第一个不确定因素是延迟。此次发布说明，符合条件的调用可在新输入到达时让出控制权，但未公布时序测量数据。用户仍需观察引导实际生效的速度。
第二个不确定因素涉及语义。“中断”“抢占”“让出”和“停止”描述的是不同操作。Codex 让出控制权后，正在运行的进程可能仍会继续，而用户可能以为工作已经结束。
清晰的界面应显示某个进程是否仍在活跃、其输出是否仍在到达，以及代理是否计划查阅该输出。这里的歧义可能导致重复命令或冲突编辑。
第三个问题是采用率。由于 instant_interrupt 默认禁用，其初期影响将仅限于发现并启用该标志的用户。
选择加入式发布提供了测试空间，但也缩小了可获得的反馈范围。经验丰富的用户对这项功能的使用方式，可能不同于首次接触代理式编程的开发者。
第四个问题涉及竞态条件。新输入可能在模型生成、执行、等待或上下文压缩期间到达。每一条路径都必须保留消息顺序，并防止工具结果附着到错误的推理步骤上。
OpenAI 表示，其测试覆盖了启用和禁用状态、重复引导、压缩期间的延迟输入，以及同一响应内的后续调用。测试还检查了排队消息和直接工具结果是否得以保留。
这些情况是必要的，但生产会话会产生更不规整的组合。开发者可能在一个回合中反复引导、更改请求的文件范围、拒绝权限，并收到延迟的进程输出。
第五个问题是安全性。更快的引导可帮助阻止正在出现的错误，但它不能替代命令批准、沙箱限制或仓库审查。
有害命令可能在修正到达前就已完成。外部服务也可能在本地代理改变方向后继续处理请求。用户不应将对话式中断视为事务性回滚。
还存在过度引导的风险。频繁修正可能导致目标碎片化，尤其是在代理保留早先上下文、且多条指令争夺优先级时。
团队将需要交互规范。一条引导消息应清楚说明发生了什么变化、它替代了哪条早先指令，以及当前执行是否应继续。
移除自动后续提示建议与此相关。Codex 0.159.0 移除了这些建议及相关设置。OpenAI 似乎正在减少未经请求的提示脚手架，同时增加更直接的用户控制。
此次发布还移除了捆绑的 plugin-creator skill。该打包变更不应与引导功能混淆，但依赖捆绑能力的用户应在升级后检查本地设置。
怀疑性的解读很直接：OpenAI 已加入更快干预所需的机制，但此次发布并未提供其提高任务成功率的证据。
这并不意味着该功能不重要。它定义了下一个评估问题：运行中引导是否能避免足够多的无效工作，从而证明增加的执行复杂性是合理的？
Codex 0.159.0 发布后值得关注的三个信号
下一项检验是，即时中断能否从实验性控制功能，转变为日常编程中可靠的一环。
第一个信号是默认状态。如果 OpenAI 在后续版本中默认启用 instant_interrupt，将表明其对顺序、保留机制和界面清晰度抱有信心。
若该功能在多个版本中始终保持选择加入状态，则表明边缘情况仍需关注。也可能意味着 OpenAI 希望用户对改变既有排队预期的行为作出明确同意。
第二个信号是围绕重复引导的问题和发布活动。有关消息丢失、命令重复、孤立进程或延迟输出的报告，会削弱即时中断的合理性。
扩大受支持工具路径的修复则会增强其价值。当前设计特别处理模型响应和长时间运行的代码模式 exec 或 wait 调用，而非所有可能的外部操作。
第三个信号是竞争对手的行为。GitHub 已通过其产品和 SDK 记录了即时引导和排队后续操作。其他编程代理供应商也面临着提供清晰运行中控制能力的相同压力。
重要的比较并不在于产品是否包含名为引导的功能，而在于修正生效的速度，以及系统解释剩余执行状态的准确性。
开发者应先在范围明确、可逆的任务上测试 OpenAI Codex 0.159.0，再在敏感工作中依赖中断。一项有用的试验可能包括一次长时间测试运行、一次范围修正，以及对仍在运行进程的检查。
检查 Codex 是否及时接收新指令。确认原始进程是否仍在运行。然后验证后续输出是否附着到正确回合，并且不会重新激活已放弃的方法。
此次发布作出了一个有说服力的产品判断：用户需要在代理完成错误工作之前进行干预的方式。现在，实施方案必须证明，在真实工作负载下，更快的干预依然易于理解。
如果你启用 OpenAI Codex 0.159.0，请从一个实际问题开始：能否在不丢失有用进展、也不对仍在运行的内容感到不确定的情况下，重新引导一项长任务？这一结果比标志本身更重要。
