Boris Cherny, the Anthropic engineer who created Claude Code, announced on February 20th that the tool now has built-in git worktree support in its command-line interface. The Desktop app has had this for a while. The CLI hadn't. Now it does.
The practical upshot: you can run claude --worktree feature-auth and get an isolated copy of your codebase, on its own branch, in its own directory, with its own Claude session. Run another claude --worktree bugfix-123 in a second terminal. The two agents work simultaneously without their edits colliding. Each worktree lands in .claude/worktrees/ under your repo root, and if you don't bother naming it, Claude picks a random name for you.
Why worktrees, and why now
Git worktrees are not new. They've been in Git since version 2.5, released back in 2015, and most developers have never touched them. The idea is simple: instead of cloning a repo twice or stashing your work to switch branches, you create a second working directory that shares the same .git history. Cheap, fast, no duplicated objects.
What changed is the use case. When you have one developer on one branch, git stash is fine. When you have five AI agents hammering the same repo at once, each making edits to dozens of files, stashing breaks down immediately. The Claude Code team had been watching users build their own worktree wrappers since at least May 2025, when a community member filed a detailed issue documenting the pattern. Engineers at companies like incident.io were already writing custom bash functions to manage worktrees around Claude sessions.
Cherny himself has been vocal about parallelization being the single biggest productivity unlock with Claude Code. In a tips thread earlier this year, he said the team's number-one recommendation was to spin up three to five worktrees at once, each running its own Claude session. Some team members use shell aliases (za, zb, zc) to hop between worktrees with one keystroke. Others keep a dedicated "analysis" worktree that only runs queries.
Subagents get isolation too
The more interesting piece, to me, is what this means for subagents. Claude Code already lets you spawn subagents to handle subtasks. Now those subagents can each run in their own worktree. For large code migrations or batch refactors, you tell Claude to "use worktrees for its agents" and each child process gets its own isolated checkout. When a subagent finishes without making changes, its worktree gets cleaned up automatically.
Custom agents can also declare this permanently. Add isolation: worktree to an agent's frontmatter and it always runs isolated. No prompting required.
The feature works across the CLI, Desktop app, IDE extensions, the web interface, and (yes) the Claude Code mobile app. Which raises a question I genuinely don't have a good answer for: who is doing parallel worktree-based agentic coding from their phone?
The rough edges
There's already a bug. Within hours of Cherny's announcement, a user on Threads reported that Claude Code had started creating worktrees on its own, without the --worktree flag. "I asked Claude Code to create a new branch to fix a bug, I see in the status bar it working in project/.worktree/branch-name," they wrote. "I didn't launch Claude with --worktrees." Cherny responded that a fix had landed and would ship in the next release, offering /permissions with "EnterWorktree" added to the deny list as a temporary workaround.
This isn't the first time worktrees have caused friction. A GitHub issue from late 2025 documented the Desktop app automatically creating worktrees for solo developers who didn't want them. Another user reported losing conversation history when worktree directories were removed, since session metadata was tied to the now-deleted path. "Worktree is a pain for me as a single developer," one commenter wrote. "I specified this in my CLAUDE.md, but Claude Code snuck it in."
The worktree-by-default behavior in the Desktop app has been a sore point. For teams running multiple agents in parallel, it makes sense. For a solo developer working on main, it adds indirection nobody asked for.
What's actually different here
Cursor has supported worktrees for a while. Third-party tools like xlaude and josegonzalez's claude-worktree CLI have been filling this gap for months. Even the incident.io engineering team published their custom wrapper back in June 2025. So native support in the CLI is less of a revelation and more of Anthropic catching up to what power users were already doing manually.
But there's a real difference between bolting on worktree support with shell scripts and having it built into the tool. The cleanup logic alone is worth something: exit a worktree with no changes and it vanishes, exit with uncommitted work and Claude asks whether to keep or discard. The --tmux flag for launching worktree sessions in separate tmux panes is a nice touch. And the subagent integration is something none of the third-party tools could replicate because they don't have access to Claude's agent orchestration layer.
Non-Git users aren't left out, either. Mercurial, Perforce, and SVN teams can define WorktreeCreate and WorktreeRemove hooks to get the same isolation behavior. I'd be curious how many Perforce shops are running Claude Code, but the option exists.
The parallelization bet
Cherny's own numbers tell the story of where this is headed. He recently shared that in a single 30-day stretch, he landed 259 pull requests, 497 commits, 40,000 lines added and 38,000 removed, all written by Claude Code with Opus 4.5. Every line. That kind of throughput only works if you can run multiple agents simultaneously without them tripping over each other's file edits.
The worktree feature is the plumbing that makes that workflow reliable. Whether most developers need five parallel Claude sessions is a different question. But for the power users who do, the days of writing custom bash wrappers are probably over.
