Codex CLI 0.162 Released: Worktree Hosting and Task Pinning

OpenAI's Codex CLI has received another significant update. Version 0.162 brings several key changes around automated Git worktree management, provider capability overrides, and background service stability. For developers who work with Agents in the terminal every day, these changes directly affect their workflows and are worth a few minutes to understand.

Worktree Hosting: Agents Branch Out on Their Own

The core new capability in 0.162 is letting the Agent autonomously create and list Git worktrees. Previously, Codex CLI typically operated within a single working directory, making parallel tasks prone to interference—one task halfway through editing, while another task needs the same files.

The new version hands worktree management to the Agent. It can create independent worktrees on demand for different tasks, each with isolated file states and branch contexts. This isolation is especially valuable when working with large repositories: one worktree runs a refactor, another handles a bug fix, and neither blocks the other.

Compared to manually running git worktree add, the advantage of Agent hosting lies in automation. It can decide whether a new worktree is needed based on task scope, saving developers from the mechanical operations of repeatedly switching directories and branches. Of course, this also means teams need to pay attention to worktree cleanup strategies to avoid accumulating large numbers of temporary worktrees in the repository.

Git worktree is a feature introduced in Git 2.5 that allows multiple working directories to be checked out simultaneously under the same repository, each bound to a different branch while sharing the same .git object store. Compared to multiple copies via git clone, worktrees don't duplicate historical objects, resulting in lower disk usage and switching costs. The typical usage is git worktree add ../hotfix hotfix-branch, then committing independently in the ../hotfix directory without affecting the main workspace. Two things to note: the same branch cannot be checked out by two worktrees simultaneously; when deleting, use git worktree remove rather than directly rm -rf, otherwise metadata will remain in .git/worktrees and will need to be cleaned with git worktree prune. This is precisely why teams must pay attention to cleanup strategies after Agents host worktrees.

Provider Capability Overrides: More Fine-Grained Model Control

0.162 introduces provider capability overrides, allowing developers to override default capability configurations for different model providers.

In real-world scenarios, different providers vary in their support for tool calling, context length, and structured output. Previously, Codex CLI dispatched based on uniform assumptions, which could cause errors when encountering providers with limited capabilities. Now you can declare capability boundaries per provider, making the dispatch logic more aligned with reality.

For users employing self-hosted models or multi-provider hybrid solutions, this reduces a common class of "configured correctly but behaving incorrectly" problems.

Here, provider refers to the actual large model service that Codex CLI calls behind the scenes—it could be the official OpenAI API, or a third-party or self-hosted inference service accessed through an OpenAI-compatible interface (such as vLLM, Ollama, or an enterprise internal gateway). So-called "capabilities" typically include whether function/tool calling is supported, parallel tool calling, JSON Schema structured output, streaming responses, system messages, reasoning fields, etc., as well as context window size. These differences don't show up in the request format—the interface returning 200 doesn't mean the model can actually output structured tool parameters correctly. The role of provider capability overrides is to explicitly declare these boundaries at the configuration layer, so that the CLI acts according to actual capabilities when dispatching tools, trimming context, and parsing responses, rather than running hard on uniform assumptions.

0.162.1 Fixes Background Server Startup Bug

After 0.162.0 was released, a background server startup issue was quickly patched, and 0.162.1 followed.

Such patch releases usually aren't worth a dedicated article, but its existence shows that Codex CLI's iteration pace is accelerating: major versions bring features, patch versions quickly catch regressions. For production environment users, choosing a patch version when upgrading is more prudent than staying on 0.162.0.

What to Do This Week

If you're already using Codex CLI, it's recommended to upgrade directly to 0.162.1, skipping 0.162.0. After upgrading, you can try having the Agent handle two parallel tasks and observe whether it automatically creates worktrees, and whether the worktree naming and location match your expectations.

At the team level, it's worth agreeing on worktree cleanup rules in advance—such as automatic deletion after merging, or limiting the number retained. Provider capability overrides need to be checked one by one against the models you actually use, explicitly configuring the limitations you previously worked around through experience.

This Codex CLI update doesn't have flashy major features, but worktree hosting does touch on a fundamental issue in Agent programming: how to safely parallelize multiple tasks on the same machine. The more cleanly this problem is solved, the more complex the work Agents can take on.

One-line Summary

Codex CLI 0.162 lets Agents autonomously manage Git worktrees and adds provider capability overrides; 0.162.1 fixes background server startup.

Paragraph Summary

Codex CLI 0.162 brings three key updates: most importantly, it hands Git worktree management to the Agent, enabling it to autonomously create and list isolated worktrees on a per-task basis, thus safely parallelizing multiple tasks on the same machine and avoiding file state interference; secondly, it introduces provider capability overrides, allowing capability boundaries such as tool calling and context length to be declared per model provider, reducing dispatch errors on capability-limited providers; 0.162.1 quickly patches the background server startup issue in 0.162.0. For developers, it's recommended to upgrade directly to 0.162.1 and to agree on worktree cleanup rules in advance and verify provider capability configurations one by one.