Codex CLI 0.169.0与0.171.0-alpha.2的会话恢复有哪些区别与限制

Codex CLI 0.169.0对会话中断、计划交接和MCP启动状态做了多处修复，适合从“任务是否真正结束、计划有没有完整交接”这两个角度理解。0.171.0-alpha.2则只有预发布身份和版本说明，没有对应功能清单，不能据此认定它包含同一组恢复修复。

先区分结束、取消与交接三个状态

会话结束意味着当前一轮的生命周期收尾；取消是针对某次正在处理的动作；清空上下文后实施计划则会把批准过的计划交给新会话。这三种状态如果混在一起，容易让开发者把上一轮的迟到取消误认为当前任务失败，或把新会话启动误认为计划已经完整传递。

0.169.0修复了被中断轮次的收尾，以及延迟中止或文件审批取消误伤后续轮次的问题。这是对不同轮次之间边界的修正，并不是让正在运行的所有任务都自动成功，也不代表用户取消过的操作会自动重新执行。

清空上下文后实施计划为什么要保留交接语义

选择“Yes, clear context and implement”时，0.169.0会向新会话交接完整批准计划；如果交接失败，当前会话保持打开。前半部分避免只传递零碎目标，后半部分让失败保留在原有上下文里，便于继续判断，而不是在交接尚未成立时就丢掉当前会话。

完整计划交接不等于代码已经实现。新的执行过程仍有自己的工具调用、权限与结果。对于需要审批的项目，把“计划已批准”“新会话已接收”“实现已完成”分别看待，才能避免把中间状态当作交付成功。

MCP等待与项目信任属于两条排查线索

0.169.0修复了共享app server没有报告某个MCP服务器时，终端仍一直等待该服务器的问题。终端不再因这类不存在的等待一直显示忙碌，并不意味着远端服务器的认证、网络或配置错误也都得到修复。

同一正式版本还明确了非交互运行的项目边界：未信任目录的项目配置与MCP服务器保持禁用，workspace-write不改变这个结论；codex exec与codex review可通过显式--trust保存项目信任。缺少工具时，需要先区分“项目未受信任而未加载”和“已加载但服务没有正常响应”，不能单凭界面忙碌或工具缺席直接归因。

平台修复与选择启用的能力不能混为一谈

Windows方面，0.169.0修复带引号的cmd.exe路径，以及PowerShell工作目录存在不可读父目录时的沙箱处理。macOS粘贴图片保留预期方向，并优先使用原生PNG或JPEG剪贴板数据。它们分别限定了平台和触发条件，不能概括成所有终端、所有图片格式都改变了行为。

终端多侧边聊天和macOS/Linux Cloud连接仍属于选择启用的能力；Cloud支持图片消息、模型与推理力度选择以及归档、恢复Cloud会话。它们提供的是工作流选项，不替代本地会话的收尾与恢复语义。0.171.0-alpha.2仍应独立看待，当前没有足够发行说明把这些细节归到该Alpha版本上。