OpenAI Codex Can Now Manage Git Worktrees Natively: A Technical Look at Parallel Agent Workflows

A week of back to back Codex CLI releases closed with a feature that sounds minor in a changelog and is not minor in practice: as of 0.162.0, shipped October 8, 2026, Codex can create and list Git worktrees inside a trusted local project directly, without a developer first running git worktree add by hand and then pointing a second agent session at the resulting directory. The release followed 0.161.0 a day earlier, which made GPT-6.1 Sol the default model across the bundled and Amazon Bedrock catalogs. Install is a one line bump: npm i -g @openai/codex@0.162.0.

We run multiple coding agent sessions in parallel against the same codebase routinely, one worktree per in-flight task, so a feature agent exists to agent that collapses from a scripted setup step into a built in command is a real workflow improvement, not a cosmetic one. It is also a useful lens for understanding why worktrees matter for agentic coding specifically, which is a slightly different reason than why they matter for human developers.

Why worktrees matter more for agents than for humans

A Git worktree lets you check out more than one branch of the same repository into separate directories simultaneously, sharing a single .git history without the overhead of a full second clone. Human developers have used this for years to, say, keep a hotfix branch checked out in one directory while continuing feature work in another, without stashing changes or switching contexts. The pattern is useful but optional for a single person working one task at a time.

For an agentic coding setup, worktrees stop being optional the moment you run more than one agent session concurrently, which is increasingly the default rather than the exception on teams that have adopted tools like Codex and Claude Code for daily work. Two agent sessions pointed at the same working directory will step on each other's uncommitted changes, checked out branch, and build artifacts. A worktree per task gives each concurrent agent session, and each task it is working, an isolated filesystem view with its own branch checked out, while still sharing the underlying object store so you are not paying full clone cost per task. Before 0.162.0, getting a Codex session into that isolated worktree meant a developer running the git command first; now the agent can do it directly inside a trusted project.

What 0.162.0 actually ships, beyond worktrees

The worktree feature requires the capability to be enabled, and once it is, Codex can create and list managed worktrees in trusted local projects as part of normal tool use rather than through a separate manual step. The same release bundled several adjacent but smaller changes worth knowing about if you run Codex day to day: Command Center gained task pinning, pressing p moves a task into a shared pinned group when the server supports it; the terminal UI added a /copy command for copying transcript blocks and Ctrl+Insert for copying a selection, plus a tui.mouse_scroll_speed setting; custom Responses-compatible model providers can now enable live web access and remote compaction; and on Windows, apply_patch now preserves existing CRLF line endings without requiring an opt-in flag, while drive-letter file access was fixed on Windows 10.

The 0.161.0 release a day earlier is simpler to summarize: GPT-6.1 Sol became the default model in both the bundled catalog and the Amazon Bedrock catalog, alongside a new /mcp login <name> command for authenticating MCP servers directly from the CLI.

How this compares to running parallel sessions by hand today

If you are already running Claude Code or Codex sessions in separate worktrees by scripting the setup yourself, which is what most teams running multiple concurrent agents have been doing, 0.162.0's contribution is removing a manual step rather than enabling something previously impossible. The practical benefit shows up most at the start and end of a task's lifecycle: spinning up a new isolated worktree for a new task, and listing what worktrees currently exist across in-flight work, both become agent-native operations instead of commands a developer runs between agent turns. For a team running five or six concurrent agent tasks against the same repository, that is a meaningful reduction in the orchestration overhead sitting outside the agent itself, even if the underlying Git mechanics have not changed at all.

When this applies to your stack

Teams standardizing on agentic coding tools for production engineering work, which is the direction JetBrains' 2026 developer survey data shows the market moving, should treat worktree-per-task as the default pattern for running more than one agent session concurrently, regardless of whether you are on Codex, Claude Code, or a multi-agent IDE workflow. If your org is still running agents serially against a single checkout because the orchestration overhead of worktrees felt like too much manual setup, 0.162.0 removes a real piece of that friction on the Codex side specifically. Setting up a parallel-agent development workflow correctly across a team, including the CI and branch protection implications of multiple agents committing to short-lived branches simultaneously, is the kind of agent engineering work we help clients get right the first time.

FAQ

Do I need to enable a flag to use worktrees in Codex? Yes, the feature needs to be enabled in trusted local projects; it is not on by default for every project without that trust designation.

Does this replace scripting my own worktree setup? For Codex specifically, yes, for the create and list operations the release covers. More advanced worktree management, like automated cleanup of stale worktrees, is not described as part of this release.

Is GPT-6.1 Sol a better model than what Codex used before? The 0.161.0 release notes state it became the default model but do not publish comparative benchmark numbers in the changelog itself; evaluate it against your own workload before assuming default equals best for your use case.

Can Claude Code do the same thing? As of this writing we are not aware of Claude Code offering an equivalent native worktree creation command; teams using Claude Code for parallel sessions still script the git worktree setup themselves.