Codex CLI 0.162 发布：工作树托管与任务固定

OpenAI 的 Codex CLI 再次迎来重要更新。0.162 版本围绕 Git worktree 的自动化管理、provider 能力覆盖以及后台服务稳定性做了几处关键改动。对于每天在终端里和 Agent 打交道的开发者来说，这些变化直接影响工作流，值得花几分钟了解。

工作树托管：Agent 自己开分支干活

0.162 最核心的新能力是让 Agent 自主创建和列出 Git worktree。过去，Codex CLI 通常在单一工作目录中操作，多任务并行时容易互相干扰——一个任务改到一半，另一个任务又需要相同的文件。

新版本把 worktree 管理权交给 Agent。它可以按需为不同任务创建独立的 worktree，各自拥有隔离的文件状态和分支上下文。处理大型仓库时，这种隔离尤其有价值：一个 worktree 跑重构，另一个 worktree 做 bug 修复，互不阻塞。

和手动 git worktree add 相比，Agent 托管的好处在于自动化。它可以根据任务范围决定是否需要新工作树，省去开发者反复切目录、切换分支的机械操作。当然，这也意味着团队需要留意 worktree 的清理策略，避免仓库里堆积大量临时工作树。

Git worktree 是 Git 2.5 引入的一项功能，允许在同一个仓库下同时检出多个工作目录，每个目录绑定不同的分支，但共享同一份 .git 对象库。相比 git clone 多份副本，worktree 不会重复存储历史对象，磁盘占用小、切换成本低。典型用法是 git worktree add ../hotfix hotfix-branch，随后在 ../hotfix 目录里独立提交，互不影响主工作区。需要注意两点：同一分支不能同时被两个 worktree 检出；删除时要用 git worktree remove 而非直接 rm -rf，否则 .git/worktrees 里会残留元数据，需要用 git worktree prune 清理。这也正是 Agent 托管 worktree 后团队必须关注清理策略的原因。

Provider 能力覆盖：更细粒度的模型控制

0.162 引入了 provider capability overrides，允许开发者针对不同模型提供方覆盖默认能力配置。

实际场景中，不同 provider 对工具调用、上下文长度、结构化输出的支持程度并不一致。过去 Codex CLI 按统一假设调度，遇到能力受限的 provider 就可能出错。现在可以按 provider 单独声明其能力边界，让调度逻辑更贴合真实情况。

对使用自托管模型或多 provider 混合方案的用户来说，这减少了一类常见的"配置对了但行为不对"的问题。

这里的 provider 指 Codex CLI 背后实际调用的大模型服务方，可能是 OpenAI 官方 API，也可能是通过 OpenAI 兼容接口接入的第三方或自托管推理服务（如 vLLM、Ollama、企业内部网关）。所谓「能力」通常包括是否支持函数/工具调用、并行工具调用、JSON Schema 结构化输出、流式响应、系统消息、推理字段等，以及上下文窗口大小。这些差异不会体现在请求格式上——接口能返回 200，不代表模型真能正确输出结构化工具参数。provider capability overrides 的作用就是在配置层把这些边界显式声明出来，让 CLI 在调度工具、裁剪上下文、解析响应时按实际能力行事，而不是按统一假设硬跑。

0.162.1 修复后台服务启动 Bug

0.162.0 上线后，后台服务（background server）的启动问题被快速修补，0.162.1 随之发布。

这类补丁版本通常不值得单独写一篇文章，但它的存在说明 Codex CLI 的迭代节奏在加快：主版本带来功能，补丁版本迅速兜住回归。对生产环境用户而言，升级时优先选择带补丁的小版本，比停留在 0.162.0 更稳妥。

本周该做什么

如果你已经在用 Codex CLI，建议直接升到 0.162.1，跳过 0.162.0。升级后可以尝试让 Agent 处理两个并行任务，观察它是否会自动创建 worktree，以及工作树的命名和位置是否符合你的预期。

团队层面，值得提前约定 worktree 的清理规则——比如合并后自动删除、或限制保留数量。Provider 能力覆盖则需要根据你们实际使用的模型逐一核对，把之前靠经验绕过的限制显式配置出来。

Codex CLI 的这次更新没有炫技式的大功能，但 worktree 托管确实触及了 Agent 编程的一个根本问题：如何让多个任务在同一台机器上安全并行。这个问题解决得越干净，Agent 能承担的工作就越复杂。