›_ Claude Code Issues
Claude Code Issues / #27044

[BUG] claude --worktree (-w) does not create a git worktree

Resolved 💬 25 comments Opened Feb 20, 2026 by kyong0612 Closed Feb 23, 2026

Description

claude -w (or claude --worktree) does not create a new git worktree. After launching with the -w flag, pwd remains unchanged, git worktree list shows only the main working tree, and .git is still a directory (not a file, which would indicate a worktree).

Steps to Reproduce

  1. cd into a git repository
  2. Run claude -w
  3. Inside the Claude session, run !pwd and !git worktree list

Expected Behavior

A new git worktree should be created and Claude should operate within it, isolating changes from the main working tree.

Actual Behavior

No worktree is created. Claude operates in the original directory as if -w was not passed.

Diagnostic Output

pwd: /Users/<redacted>/Dev/<project>
git worktree list: /Users/<redacted>/Dev/<project>  e09387f [main]  (only one entry)
git rev-parse --show-toplevel: /Users/<redacted>/Dev/<project>
git branch --show-current: main
echo $CLAUDE_WORKTREE: (empty / not set)
ls -la .git: regular directory (not a file)

Key observations:

  • Only one worktree exists (the main working tree)
  • .git is a directory, not a file (worktrees use a .git file pointing to the main repo)
  • CLAUDE_WORKTREE environment variable is not set
  • ~/.claude-worktrees directory does not exist

Environment

  • Claude Code version: 2.1.49
  • OS: macOS
  • Git: installed and functional
  • Executed inside a valid git repository on the main branch

View original on GitHub ↗

25 Comments

dbabokin · 4 months ago

I have the same problem. OS: Ubuntu 22.04 (git version 2.34.1)

dkodr · 4 months ago

Same on Windows (native).

joshua-redmond-1st · 4 months ago

Yeah, same for me.

Ubuntu 22.04.
Git v2.34.1.
Claude Code v2.1.49.

I've never tried it before so not sure if it used to work.

Happy Birthday Claude Code :)

zakariamehbi · 4 months ago

Same issue on MacOS

crobbo · 4 months ago

Same issue MacOS.

andykreed · 4 months ago

Same issue

  • Claude Code version: 2.1.50
  • Platform: macOS (Darwin 25.2.0)
  • Node: v24.3.0
  • Git worktrees are otherwise functional in the repo (existing worktrees work fine)
norbinsh · 4 months ago

same issue, tried both -w and --worktree

dbabokin · 4 months ago

For me started working with 2.1.50 on the SECOND attempt. First run - no worktree create. Second and later runs - work.

andybergon · 4 months ago

Same issue on v2.1.50, macOS. Flag is silently ignored — no worktree created, no error. git worktree add works fine manually from the same repo.

Zakisb · 4 months ago

Same issue !

lionhylra · 4 months ago

Claude says it's because it doesn't support ghe url, so repository will be null.

mohamedmagdy17593 · 4 months ago

Same issue on mac os

narhc8 · 4 months ago

Confirming this on v2.1.50 (macOS, Darwin 25.1.0, Apple Silicon).

Same behavior — --worktree <name> does not create a git worktree. Additional findings from testing multiple parallel sessions:

Test 1: Two named worktree sessions

# Terminal 1
claude --worktree session2a

# Terminal 2
claude --worktree session2b

Both sessions operated on the same working directory (confirmed via lsof -p <pid> showing identical cwd). No .claude/worktrees/ directory was created. git worktree list showed only the main checkout. Both sessions modified the same files simultaneously, causing conflicts.

Test 2: Pre-creating .claude/worktrees/ directory

Manually created .claude/worktrees/ before launching claude --worktree test-isolation — made no difference. The directory remained empty and no git worktree was created.

Environment:

  • Claude Code: 2.1.50
  • OS: macOS 15 (Darwin 25.1.0)
  • Shell: zsh
  • Git: functional, inside a valid repo on a feature branch
norbinsh · 4 months ago

also doesn't work on claude code desktop... @bcherny any ideas?

norbinsh · 4 months ago

I asked Claude Code (Opus) to help debug this — it reverse-engineered the v2.1.50 binary and traced the full code path.
The --worktree flag is parsed correctly by Commander.js, but its value is silently discarded before it's ever used:

// In the CLI action handler:
zT = nNT() ? H.worktree : undefined // ← gate check

// nNT() is isWorktreeModeEnabled():
function nNT() {
return A9("tengu_worktree_mode", false); // remote feature flag, defaults to false
}

When isWorktreeModeEnabled() returns false H.worktree is replaced with undefined, and the entire worktree creation block is skipped. No error, no warning.

Claude patched it locally for me and it works now --- but now i am confused on why our accounts don't get the FF toggle? maybe a transient network error blocking it?

Edit: doesn't seem like a network error, i see 86 other flags returning just fine - the worktree one isn't.

<img width="415" height="213" alt="Image" src="https://github.com/user-attachments/assets/4f4c9dca-c8b5-44db-a18a-069554094860" />

jiangyan · 4 months ago

same here, for both windows terminal, and WSL, with version 2.1.50
BUT, the claude desktop worktree works, LOL, really weird!

<img width="965" height="969" alt="Image" src="https://github.com/user-attachments/assets/6cc27d79-ad60-47f5-a883-8088eecefdbb" />

Gillysuit · 4 months ago

Same for me on macOS. It worked for a couple of sessions, but started to silently fail.

I sent Claude @norbinsh 's comment, and it self-patched, working now. thanks

pmatos · 4 months ago

Created scripts to patch 2.1.50 directly.
x86: https://gist.github.com/pmatos/2ef30b3d7fe808546cd8cdf84abe7fde
arm64: https://gist.github.com/pmatos/b3f9a593b6b734e693f3886853826b58
Hopefully this is fixed soon.

stevenpetryk · 4 months ago

Hey folks, thanks for reporting. This feature flag has been rolled out to 100% of users for a few days, but a logic error was preventing it from working depending on the feature flag cache. I'm working on a fix now.

stevenpetryk · 4 months ago

This should go out with today's v2.1.51 release. Thanks for reporting!

wesleyfranks · 4 months ago

same issue here macos 26.3

stevenpetryk · 4 months ago

If anyone continues to see this behavior on the latest version (currently 2.1.52), please let me know here. I am going to assume the intervening comments/duplicate issues are people on stale versions.

kyong0612 · 4 months ago

Thanks for the quick fix! Confirmed working on the latest version.

donataskairys · 4 months ago

I'm using Mac v2.1.63. It seemed to work for a while, but then it started reusing the same workspace. Three features got mashed together until I noticed. The Cladue code shows different names for the workspaces, but the paths are the same for all.

github-actions[bot] · 4 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.