OpenAI Codex 0.160.0 将可靠性打造为智能体的核心功能

OpenAI Codex 0.160.0 带来了四项新功能和六类修复，但其真正的变化并非表面优化，而是运营层面的升级。该版本于 2026 年 10 月 1 日发布，让持续运行的智能体会话更易于查找、恢复、监管，并能在中断后复原。

这一重点形成了鲜明对比。编程智能体常常因单项任务中产出的代码而被评判。如今，OpenAI 正在大力投入任务周边的一切，包括历史记录、权限、交接、连接恢复和环境设置。

主要竞争已不再只是 Codex 与 Claude Code、GitHub Copilot 或其他编程助手之间的较量，而是持久化智能体运营与一次性聊天模型之间的较量：后者每个会话都从零开始，故障也彼此隔离。0.160.0 版本表明，OpenAI 预计开发者将把智能体工作视为可持久保存的运营状态。

OpenAI Codex 0.160.0 实际带来了哪些变化

此次更新将多个隐藏的故障点转化为 Codex 工作流中可管理的环节。

官方 0.160.0 release 将更新分为新功能、错误修复、文档和维护工作。重点新增内容涵盖任务历史、Linux 终端交互、无项目会话以及可选的 Guardian 审查上下文。

任务历史迎来了最显眼的变化之一。智能体命令中心此前仅加载十个最近会话，无法直接访问更早的工作记录。现在，支持键盘操作的“显示更多”行每次请求可再发现最多十项任务。

这并不只是给列表增加了分页。Codex 会为不同的历史来源分别保留游标和缓冲结果，再按时间新近程度合并交互式与非交互式会话。

当后续请求失败时，界面还会保留已有结果。在任务被归档或删除后，它会补充空位，同时避免过期刷新重新显示已移除的任务。当历史记录成为运营档案而非便利菜单时，这些细节至关重要。

Linux 用户也获得了一项交互修复。在受支持的本地 X11 终端全屏模式下，用户可以选中转录文本，并通过中键点击使用主选择区粘贴。这一行为让 Codex 更贴近既有的终端使用惯例。

无项目会话获得了更具影响力的更新。Codex 现在可以在未识别为项目的目录之外，使用工作区默认设置开始工作，但前提是本地配置和受管策略允许这种行为。

恢复的任务可还原其保存的权限配置，除非用户明确覆盖。普通轮次不应覆盖服务器保存的配置。明确作出的审批审查选择仍与恢复的任务权限相互独立。

此次发布还扩展了 Guardian——一个用于评估智能体拟议操作的自动化审查层。两项可选功能允许 Guardian 获取更早的用户指令，并接收从智能体交接中选取的上下文。

两项 Guardian 新功能默认均处于禁用状态。这一区别很重要，因为这些变化扩大了操作审查期间可用的上下文。OpenAI 将其定位为受控的安全能力，而不是悄然应用于所有会话的通用行为。

错误修复进一步强化了同一主题。Codex 可在重连后恢复排队消息，而不会盲目重发状态不明的提交。它保留了更多终端设置，修复了多处 Windows 沙箱路径，并改进了子智能体环境继承。

OpenAI 还解决了 SQLite 卡顿、误导性的初始化超时、过期的提供商目录、重复的插件解析以及未使用的日志数据库空间等问题。这些改动不会改变模型表面上的智能程度，却减少了智能体工作流变得混乱或不一致的可能性。

这正是此次发布的重要之处。它将智能体周边系统视为产品的一部分，而非用户只能忍受的底层管道。

更早的任务让命令中心成为运营档案

可搜索、可扩展的历史记录，将 Codex 从一连串提示词转变为具备记忆的工作区。

在此次更新之前，命令中心只加载十个最近会话。用户可以在界面已加载的内容中搜索，却没有直接方式持续回溯到更早的任务历史。

新的 task pagination 设计增加了可选中的“显示更多”行。它在搜索期间仍然可用，并包含为键盘导航设计的加载和重试状态。

每次增加十项任务听起来不多。关键在于，OpenAI 为不断增长的历史记录设计了配套的状态管理。

Codex 为每个来源保存游标，并在请求之间缓冲结果。它按时间新近程度合并不同会话类型，而不是假定存在一个统一来源。如果请求失败，已加载的任务仍会保持可见。

这种行为支持常见的开发场景：某个新 bug 暴露出相关症状后，用户可能需要回到数日前的一次调查。若刷新失败时较早的条目消失，历史记录就会变成不可靠的索引。

此次更新还将常规详情刷新限制在最近、已加载或被明确请求的线程中。随着可见任务集扩大，这一选择控制了后台工作量。它表明 OpenAI 预计历史记录集合将显著增长。

持久化历史给简单助手采用的一次性会话模式带来了压力。短暂存在的助手只需回答当前提示词；持久化智能体则必须跨时间保留身份、排序、配置和权限。

这种差异改变了用户的预期。一旦任务出现在命令中心，它就开始更像一项工作事项，而非聊天记录。用户会期待能够找到、恢复、分叉它，并了解其当前状态。

团队也获得了更清晰的路径来恢复推理与实现上下文。一项任务可保留生成补丁的过程，包括后续修正。这可以补充包含规格、决策和本地技术文档的 可搜索知识库。

历史记录仍有局限。分页并不等同于语义检索、项目报告或正式审计日志。此次发布并未声称提供这些系统。

命令中心还需要呈现混合任务来源，而不制造虚假的等同性。交互式本地会话的假设条件可能与远程执行任务不同。将它们一同排序有助于发现，但不会消除这些差异。

OpenAI 的实现通过按来源保存游标和合并排序承认了这一复杂性。它还防止过期请求重新带回已删除的任务，这是一条微妙但重要的一致性规则。

这使会话历史成为共享基础设施。恢复、分叉、搜索、删除和归档都依赖于同一份记录的可预测行为。

Claude Code 和 GitHub Copilot 面临相同的更广泛产品压力，即使它们的界面不同。随着编程助手承担更长周期的任务，用户将要求获得持久化历史，而非彼此孤立的对话窗口。

因此，竞争问题不在于谁展示的列表最长，而在于哪款产品能让旧有智能体工作足够可信，从而可以被复用。

对 OpenAI 而言，“显示更多”是可见的控制项。更大的转向在于承认：智能体历史需要与其他开发者系统同样细致的状态管理。

重连修复应对最昂贵的一类不确定性

编程智能体必须区分真正失败的工作，与仅仅状态未知的工作。

网络中断会为任何有状态智能体带来难题。客户端可能在发送消息后、收到确认前失去连接。重发该消息可能重复执行操作，放弃它则可能遗弃用户请求的工作。

OpenAI 的 reconnection fix 将未发送的消息与已提交但尚未确认送达的消息区分开来。Codex 会利用恢复历史、缓冲事件和后续回执中发现的精确客户端消息标识符，协调提示词和引导消息。

已确认的提交会离开恢复队列。从未发送的消息可在重放后恢复。状态不明的提交则会保持暂停，而不会再次传输。

界面还会标明无法确认送达的那条消息。这让用户能够解决具体的不确定性，而不是面对笼统的连接警告。

这一差异之所以重要，是因为智能体提示词可能引发副作用。重复请求可能会两次编辑同一个文件、再次调用外部操作，或在第一次已成功后创建第二份结果。

传统聊天客户端通常可以容忍重复文本。智能体系统却不能假设重复无害。它的消息可能对应操作，而不只是对话。

OpenAI 保留了针对不可用对话、待处理压缩或审查请求，以及既有恢复故障的暂停机制。换言之，自动恢复只适用于客户端能够建立安全状态的场景。

这是一项关于幂等性压力的实际案例。幂等性意味着重复执行一项操作与执行一次具有相同效果。许多智能体操作天然并不具备幂等性，因此客户端必须避免草率重放。

此次发布并未宣称可在所有故障条件下实现完美恢复。缺失的历史记录或延迟确认仍可能使提交状态不明。更安全的做法是暴露这种不确定性。

这一选择揭示了持久化智能体的核心权衡。更多自动化可以减少摩擦，但当系统缺乏足够证据时，自动恢复也可能带来风险。

OpenAI 通过仅恢复已知未发送的输入来解决这一特定权衡。它会暂停存在歧义的情况，并要求用户检查。这不如无条件重放流畅，却能防止重复执行。

同一原则也出现在 OpenAI Codex 0.160.0 的其他地方。无项目会话只有在策略允许时才获得工作区默认设置。Guardian 仅通过可选功能获得额外上下文。子智能体会保留待处理环境，而不会假装这些环境已经就绪。

这些变化偏向明确状态，而非乐观假设。这种方法或许显得保守，但随着智能体处理更长的序列和更具影响力的工具，其价值会愈发明显。

终端 UI 还会保留服务器提供商、推理摘要和详细程度设置。恢复与分叉历史现在使用正确的模型提供商查找机制。这些修正可防止恢复后的会话看似相同，却在无声中使用了不同配置。

对个人开发者而言，收益是连续性。连接中断不应抹去排队工作，也不应重复请求。

对企业用户而言，风险更高。状态不明的提交会使责任追溯变得复杂，尤其是在智能体能够修改代码仓库或与已连接服务交互时。可恢复状态必须同时保留意图和证据。

持久化的智能体操作正是在这里比一次性对话更具优势。一次性会话可能直接失败。一个持久系统则必须解释发生了什么、保留仍然有效的内容，并在确定性终止之处停止。

Guardian 获得更多上下文，但更多上下文并不自动意味着更安全

Guardian 能够审查更多用户意图，但审查质量仍取决于上下文选择和当前策略。

自动化审查器只能评估其接收到的证据。如果智能体在长时间对话后提出一项操作，最新的转录片段可能遗漏最初授权该操作的指令。

新的可选 history retrieval 功能旨在弥补这一缺口。当它与 Apps 一同启用时，Guardian 可以通过父会话的实时连接和会话身份搜索并读取更早的用户消息。

其要解决的场景很明确：被截断的转录记录可能遗漏早先的指令、限制或已撤销的权限。Guardian 在批准具有副作用的操作前，需要获取相关历史记录。

该实现会在每次调用时重新检查父级当前的应用和工具策略。已禁用的工具仍不可用，需要审批的调用将被拒绝。此前可用的工具不会因历史上下文而获得永久授权。

OpenAI 还要求审查器区分用户授权与由助手生成的上下文。这能防止早先的一条助手表述被视为等同于用户许可。

后续撤销同样重要。如果用户此前允许某项操作，随后又收回许可，最新指令应当主导审查。检索设计明确考虑了结果不完整和授权变化的情况。

历史响应采用约 4,000 个 token 的默认限制。管理员可以配置这一上限，而父级或审查器更严格的限制仍将继续适用。

第二项可选功能会围绕智能体交接选择根上下文。对于每一次相关交接，Guardian 可以获得此前三条根消息；它还可以获取最近三条根消息，以便近期取消操作仍然可见。

这有助于父智能体将工作委托给子智能体的情形。子智能体的本地转录记录或许能说明被分配的任务，却可能遗漏使该任务获准执行的更广泛授权。

不过，额外上下文不等于完整理解。检索可能遗漏相关措辞，选定的交接窗口也可能排除边界之外的指令。更长的转录记录还可能包含互相矛盾的请求。

该功能默认仍处于禁用状态，这限制了即时暴露范围。这一状态也意味着，用户不应假定每次 Guardian 审查都会查阅其完整对话历史。

隐私和数据处理值得关注。启用该选项后，实现会使用父级的实时 Apps 连接和会话身份。组织应了解哪些消息会进入审查路径。

审查系统还保留了授权与任务上下文之间的区分。这一边界至关重要。了解智能体为何接到某项任务，并不会自动授权它采取可能选择的每一种操作。

这正是此次发布的核心权衡。持久化智能体需要更多上下文来避免不安全的误解，但更广泛的上下文也扩大了审查器必须正确处理的材料范围。

OpenAI 的防护措施针对了几个显而易见的失效模式，包括实时策略检查、消息限制、默认禁用、撤销感知，以及针对具有显式扩展注册表的会话的隔离规则。

不过，公开的拉取请求提供的是实现说明和测试覆盖，而不是有关真实世界审查准确性的独立证据。用户不应将 Guardian 视为范围明确的权限和人工确认的替代品。

最好将该功能理解为纵深防御的一部分。它可以帮助审查器定位相关证据，却无法保证每一项模糊授权都会得到正确解释。

这种不确定性应当影响采用方式。团队可以在受控工作流中启用该功能，观察审查行为，并让重要操作始终处于明确审批之后。

无项目会话扩展访问范围，同时不放弃策略

Codex 现在可以更轻松地在正式项目之外启动，同时仍由权限检查作为控制边界。

编码工作并不总是在代码仓库中开始。开发者会检查配置目录、临时导出文件、日志、生成文件，以及尚未成为项目的文件夹。

此前的项目假设可能会在这些情形中增加阻力。OpenAI Codex 0.160.0 引入无项目终端会话：当本地执行、配置和受管策略允许时，它们将采用工作区默认设置。

对于本地发现、且没有保存信任决定的无项目目录，实现可以跳过文件夹信任提示。它仅在相关策略允许时，应用工作区写入权限和细粒度审批默认设置。

Windows 获得了一项额外防护措施。在启用隐式工作区写入权限前，如有需要，Codex 会提示设置沙箱。

该更新还会在恢复任务时还原已保存的任务权限，除非用户明确覆盖它们。这能避免恢复后的任务悄然回到不同的权限配置。

普通对话轮次不应覆盖服务器保存的配置。通过审批审查器作出的明确选择仍会被单独跟踪。这种分离减少了对持久任务策略的意外更改。

目录变更也获得类似处理。/cd 命令可以请求文件夹信任，并提供“保留当前目录”选项。Codex 会在切换位置前重新检查任务活动状态和后台终端。

它还会对目标位置执行权限要求。因此，目录变更仍是一种策略转换，而不只是路径更新。

直接收益是灵活性。开发者可以围绕一组零散文件启动调查，而不必先将其整理为已识别的项目结构。

更广泛的影响涉及工作区身份。如果智能体可以在代码仓库之外运行，项目边界便不能再承载关于信任、存储和权限的全部假设。

这加大了对显式策略的要求。工作区默认设置、已保存的任务配置、目录信任和沙箱就绪状态，成为定义允许行为的机制。

此次更新并未取消同意机制。它改变的是同意如何被表示，以及 Codex 何时可以推断出安全默认值。

这一差异对于比较 OpenAI Codex、Claude Code 或 GitHub Copilot 工作流的用户尤为重要。灵活的入口只有在恢复任务、切换目录和还原权限都能带来可预测结果时才有价值。

无项目操作还可能使智能体更适用于更多知识工作任务。技术调查通常会将源代码与规格说明、日志、会议记录和生成报告结合起来。

开发者或许会通过 knowledge blending 汇集这些上下文，再让智能体基于形成的证据开展工作。当这些来源包含敏感材料时，权限边界必须保持清晰。

怀疑的观点很直接：默认设置可以降低摩擦，同时也可能让权限变化变得不那么显眼。用户可能会将“策略允许”误解为“对这项具体任务安全”。

OpenAI 部分通过区分已存储权限和明确的审查器选择来应对这一风险。当目标位置需要不同的信任决定时，它也会保留目录同意机制。

发布说明没有提供采用数据或企业事故结果。没有依据可以声称，无项目会话在每一种环境中都比绑定代码仓库的会话更安全。

有意义的改变更为有限：Codex 可以在更多地方开始工作，同时不放弃其策略模型。组织是否接受这一平衡，将取决于其受管配置和审计需求。

三项信号将显示这一可靠性战略是否奏效

下一项考验在于：这些状态管理改进能否在真实工作负载下保持可理解性。

第一项信号是 Guardian 可选上下文功能的采用情况。OpenAI 应观察用户是否会在持续性工作流中启用对话历史检索和交接感知审查。

如果采用率上升而令人困惑的审批没有相应增加，上下文策略就会获得可信度。如果团队始终关闭这些选项，新增能力可能过于难以治理。

最有价值的证据应描述错误批准、不必要拦截、遗漏撤销和审查器延迟。仅有功能开关无法说明 Guardian 是否正确解读了检索到的指令。

第二项信号是连接不稳定时的恢复行为。新的队列逻辑区分未发送消息和提交状态不确定的请求。真实会话将会在长任务、多设备和延迟的服务器回执中检验这一差异。

更少的重复操作将强化 OpenAI 的持久工作区论点。即使暂停仍比自动重放更安全，频繁的不确定性提示也会削弱这一论点。

用户还应关注未来版本是否将同一协调模型应用于更多事件类型。智能体系统除普通提示外，还会产生工具调用、审查、交接、环境变更和终端输出。

第三项信号是命令中心历史记录是否会成为更广泛任务管理的基础。分页解决了访问更早会话的问题，但长期采用将带来对更强检索和组织能力的需求。

有用的下一步可能包括更丰富的筛选条件、更清晰的任务状态、持久标签，或会话与最终代码变更之间更好的关联。这些可能性尚未作为已发布功能宣布，因此它们仍是观察点，而非承诺。

同样的信号也适用于竞争对手。如果其他编码智能体强调可恢复任务、权限连续性和可恢复状态，市场便是在验证持久化操作是一项核心产品类别。

OpenAI 的后续版本还应揭示，这套架构会在多大程度上延伸到子智能体。0.160.0 版本已经会在生成子智能体时保留仍处于启动状态的环境。

子智能体会获得原始环境之后的配置或失败结果，而不会失去该环境。待处理的配置等待也可以在执行器重试时继续存在。

这减少了一种竞态条件，即操作结果会因时序变化而不同。仅仅因为准备尚未完成，稍早启动的子智能体不应获得不同的环境。

这一方向在整个发布中保持一致：较早的会话仍然可发现；排队消息可在重连后继续存在；恢复任务时权限会被还原；Guardian 可以恢复相关授权上下文；子智能体会保留仍在准备中的环境。

这些变化都不能保证生成更好的代码。但它们共同解决了用户能否信任代码生成周边流程的问题。

这一流程正在成为竞争界面。模型质量依然重要，但持久化智能体工作同样依赖恢复能力、权限边界、上下文来源和可见的不确定性。

因此，OpenAI Codex 0.160.0 并非一次引人注目的能力发布，而是一次基础设施更新，旨在让智能体表现得更像持久协作者，而非一次性提示响应器。

开发者应在自己最不规整的工作流中测试这次更新：恢复一项旧任务、中断连接、在仓库外启动，并检查哪些权限会恢复。

评估编程代理的团队应直接提出一个问题：系统能否说明一次中断后，哪些内容得以保留、哪些发生了变化，以及哪些仍存在不确定性？

如果在真实工作中，这个答案依然清晰，那么 OpenAI 的可靠性策略正在奏效。若用户仍必须手动重建状态，那么该指挥中心就仍只是脆弱会话之上的精致视图。