Codex CLI 0.162: Managed Worktrees and Pinned Tasks

TL;DR
Codex CLI 0.162.0 lets the agent create and list its own Git worktrees, adds provider capability overrides, and 0.162.1 patches a background-server startup bug. What to change this week.
If you run Codex CLI in more than one checkout, the 0.162 line is the one to read before you upgrade. OpenAI tagged Codex CLI 0.162.0 on October 8, 2026, and shipped 0.162.1 a day later as a two-bug patch. The headline is that the agent can now create and list Git worktrees for itself.
Last updated: October 10, 2026
Search interest in "codex cli" is steady and high. On a 30-day Google Trends comparison pulled today it averaged 35 on the index, against 11 for "claude code skills" and 6 for "codex update". Almost nobody searches for the specific features yet, which is why a plain account of what changed is useful.
What 0.162.0 actually ships#
From the release notes, the user-facing features are:
- Tools for creating and listing managed Git worktrees from trusted local projects, when the worktrees feature is enabled.
- Pinning tasks in the agent Command Center with
p, kept in a shared Pinned group when the server supports it. - Transcript copy and navigation through
/copy,Ctrl+Insertto copy a selection, and atui.mouse_scroll_speedsetting. - Clickable URLs in approval headers, questions, MCP prompts, warnings and banners, including links that wrap across lines.
- Live web access and remote compaction settings for custom Responses-compatible model providers.
- JavaScript helpers for streaming promise results as they settle, plus opt-in ranked tool search in Code Mode.
The bug-fix list matters just as much if you run unattended agents: apply_patch now preserves existing CRLF line endings without an opt-in, the Linux sandbox starts correctly with multiple denied files, and the client honors the server's Retry-After advice on retryable Responses and WebSocket failures.
The angle: worktrees become an agent tool, not just a flag#
Earlier worktree support was something the human invoked. Codex CLI 0.154 added experimental --worktree and /worktree, which made a session durable. In 0.162 the model gets the capability directly.
The pull request that added it says it exposes create_worktree, get_worktree_creation_status and list_worktrees through MCP when the worktrees feature is enabled for a trusted local project. Several design choices are visible in the description:
- Creation is asynchronous. The model polls a status tool instead of blocking.
- The worktree defaults to the repository's remote default branch unless a
refis supplied. - The task's working directory and execution environment stay unchanged, and uncommitted source changes stay where they are.
- Creation is rejected in ephemeral side conversations and in explicitly untrusted source projects.
- Configured MCP servers that conflict with the TUI tools namespace are rejected.
The last two are the security story. A worktree is a second checkout with its own files on disk, so letting a model create one is a trust decision, and Codex ties it to the project trust state you already set. The namespace rule means a third-party MCP server cannot shadow the built-in tool names.
What does a builder do with this on Monday? Not much changes until you hand the agent a task that wants isolation. The practical pattern is the one in our Git worktrees guide for parallel agents: one branch per task, one review boundary per task. The difference is that you can now say "do this risky refactor in its own worktree and report back" in the prompt, rather than creating the directory yourself first. I have not verified how the feature flag is named in config.toml, so check codex --help and the docs for your build before assuming it is on.
One caveat on the tool surface: the PR says the tools are exposed to the model "through MCP". If you audit tool lists or pin an allowlist, expect three new names to appear after the upgrade.
Custom providers get capability overrides#
If you point Codex at something other than OpenAI, the capability-override PR is the more important one. Per its description, Responses-compatible providers can now set two things under model_providers.<id>.capabilities:
# Example from the pull request description, not a full config
[model_providers.custom.capabilities]
external_web_access = false
remote_compaction = "v2"
external_web_access = false keeps hosted web search from touching the live web. remote_compaction accepts v2, which sends compaction_trigger items through the Responses endpoint, or unsupported, which falls back to local compaction. Omitted capabilities keep the existing provider defaults.
If you run a gateway or a local server that does not implement remote compaction, unsupported is the setting to try when long sessions misbehave. Our custom providers guide has the surrounding config.toml blocks. Treat the snippet above as a template to adapt, and test it against your own endpoint.
What 0.162.1 fixes, and why you want it#
The patch release is small, but one line is relevant if you work across worktrees. It fixes startup failures caused by differences between a running background server's feature settings and the CLI defaults, so compatibility checks now apply only to explicit command-line feature overrides. It also fixes a TUI crash when asynchronous questions contain multiple lines.
Both fixes come from the 0.162.1 release page. If you are on 0.162.0, move to 0.162.1.
What people are actually saying#
The conversation is on Reddit, and it is mostly practical rather than celebratory.
- A r/codex thread from a user who runs the CLI in multiple worktrees says that starting Codex in a new worktree often fails with a background-server error. The release notes do not link that thread, so I cannot say the 0.162.1 fix closes it, but the symptom is close to what the patch describes.
- Another r/codex thread asks where the "Create permanent worktree" option went in the desktop app. It is a reminder that worktree handling is changing across surfaces, and the CLI and app do not always match.
- Windows users are the sharpest critics. A r/codex thread reports delegated tasks failing on a bundled CLI at 0.162.0-alpha.2. That was a pre-release build, and the stable notes list several Windows fixes, but it is the counter-case to "just upgrade".
- A community summary post on r/CodexAutomation covers the release in much the same terms as the official notes.
My read: nobody is complaining that the feature is wrong. The complaints are about startup state and cross-surface consistency, which is what you would expect when an agent runtime starts managing filesystem state on its own.
Do this before you upgrade#
- Pin the version you tested: check
codex --versionbefore and after. - If you allowlist tools, add the three worktree tool names deliberately or confirm the feature stays off.
- If you use a custom provider, test
remote_compactionagainst a long session before relying on it. - Keep human review at the merge step. A worktree isolates files, not judgment. Our notes on resource budgets and long-running agent harnesses cover the limits that still apply.
FAQ#
What is new in Codex CLI 0.162.0?#
Managed Git worktree tools the agent can call, task pinning in the Command Center, transcript copy and navigation, clickable links in prompts, provider capability settings for web access and remote compaction, and Code Mode helpers, plus sandbox and Windows fixes.
Does Codex CLI 0.162 create worktrees automatically?#
Only when the worktrees feature is enabled for a trusted local project. The tools are rejected in ephemeral side conversations and untrusted source projects.
What does 0.162.1 change?#
It fixes a TUI crash on multi-line asynchronous questions and a startup failure caused by mismatched background-server feature settings.
Should I upgrade from 0.162.0 to 0.162.1?#
Yes. It is a bug-fix release, and the startup fix affects anyone who runs a shared background server across checkouts.
Continue Reading#
- Codex CLI Worktrees Turn Agent Runs Into Durable Sessions - the 0.154 release that introduced worktrees
- Codex Custom Model Providers - tested config.toml blocks for non-OpenAI endpoints
- Git Worktrees for Parallel Agents - the branch-per-task pattern
- Codex CLI Resource Budgets - limits that still apply to long runs
- Long-Running Agents Need Harnesses - why review boundaries matter
- Codex CLI Background Daemon: How to Turn It Off - the default-on daemon that arrived in 0.157.0 and the reported workaround
Sources#
- Codex CLI 0.162.0 release notes - OpenAI, October 8, 2026
- Codex CLI 0.162.1 release notes - OpenAI, October 9, 2026
- Add managed worktree tools to the TUI (#50148) - pull request description
- Add capability overrides for custom model providers (#50459) - pull request description
- r/codex: constantly tripping over background server
- r/codex: where did "Create permanent worktree" go
- r/codex: delegated tasks on Windows
- r/CodexAutomation: 0.162.0 summary
- Google Trends, 30-day comparison of "codex cli", "codex worktree", "claude code skills", "codex update", "codex changelog" - pulled October 10, 2026
Get the next deep dive like this in your inbox
One email a week on Codex and the rest of the AI dev stack. Free.
Read next on AI coding tools
Codex CLI Worktrees Turn Agent Runs Into Durable Sessions
Codex CLI 0.154.0 adds experimental worktrees, inline answers, Windows daemon support, and approval hardening. The important shift is durable agent workspace control.
7 min readCodex Custom Model Providers: GLM-5.3, Mistral and Ollama
Codex only speaks the Responses API now. Tested config.toml blocks for GLM-5.3, Mistral Large 4 through a gateway, local Ollama and an internal proxy.
14 min readGit Worktrees + Claude Code: Run Parallel Agents in 2026
Several Claude Code agents on one repo cause branch collisions and stash chaos. Git worktrees give each agent its own directory on one shared Git history.
7 min readNew here? Start with
Technical content at the intersection of AI and development. Building with AI agents, Claude Code, and modern dev tools - then showing you exactly how it works.








