[BUG] Option to disable automatic worktree creation for solo developers (for the standalone macOS interface)

I asked Claude if this should be considered bug (potential data loss) or feature request (it's likely currently working as designed). His response:

I'd argue it's both, but leans toward bug for these reasons: Bug argument: - Silent data divergence is a defect, not a feature. If a user reasonably expects their files to be edited and they're not, that's broken behavior regardless of intent. - Missing uncommitted changes without warning could lead to real data loss or wasted work - you could spend an hour having Claude build on an outdated state. - The principle of least surprise is violated. Feature request argument: - It's technically "working as designed" (worktrees are intentional) - The fix is adding UI/warnings, not changing core behavior My suggestion: File it as a bug with the framing: "Claude Desktop silently creates a git worktree without user consent or notification, causing edits to diverge from the user's working directory. Uncommitted changes are not visible to Claude, risking wasted work or confusion. At minimum, this should require explicit opt-in or display a clear warning." The "silent" and "without consent" aspects make it a bug in user experience, even if the underlying implementation is intentional. A feature that can cause data confusion without warning is a bug.

Here's the key: On my first use of Claude Code on Desktop today, I DID lose data because of this (retrieved from backup, but still).

I think I should at least get a clear notification/explanation (even for novice git users) that this is what's happening when I start the chat.

However, I'd prefer this to be entirely opt-in.

I have enjoyed the inline (within VSCode) experience of Claude Code so far -- in particular editing and collaboration on live uncommitted files in main (or other current branch chosen by me) in original folder -- but would love the centralized history and other features in the new desktop app. So essentially I believe the desktop app should work that way, or at least have the option to.

The git worktree requirement is extra work/friction (eg. to have to keep merging Claude's changes back into my main branch). The option to just work together in the main branch, in live uncommitted files, would be ideal, and in turn would resolve the "silent" and "without consent" part, anyway.

Understood the way this is working is probably as designed, but I DID lose some changes because I DIDN'T realize this is what it was doing. I've been using Claude Code within VSCode before now, and so I had no reason to believe it behave significantly differently. Also, I'm a fairly basic git user. I use git for basic version control, and almost never use multiple branches. I've never used "check out" before, and so I didn't understand that's what it was doing until after I realized the data loss and ... well, thankfully Claude explained it all to me and I figured it out. For what it's worth, as noted, Claude agreed with me that this is a potential danger 😉.

Sorry if too much detail. Wanted to be thorough.

macOS 26.0.1
VSCode 1.106.3
Claude for Mac "1.0.1307 (1ed883) 2025-11-25T21:34:53.000Z"

I STRONGLY agree!...I'm a solo developer on a project and work exclusively on my develop branch which I test locally and then PR merge to my staging and deploy to my test env using git workflows. But the default worktrees behavior throws this whole process into a mess with me having to ask Claude to merge all changes to develop each time...it's confusing, added work and unnecessary.

Oh BTW I'm running into this on Windows desktop version.

I also am finding this new feature to be a productivity killer for my solo project. If I make changes, Claude can't see them and flails around looking for them and is unable to get where it needs to be, or stop using separate worktrees.

It is work to set up al alternate path in teh prompt. It wastes token for the AI to get it right the first time and then it forgets and wastes more token (and my time). For solo devs, teh main branch is the easiest one. I’m sure solo devs are quite a few in number?

On Dec 3, 2025, at 9:27 AM, Roger Levy @.***> wrote: RogerLevy left a comment (anthropics/claude-code#12513) <https://github.com/anthropics/claude-code/issues/12513#issuecomment-3607126718> I also am finding this new feature to be a productivity killer for my solo project. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/12513#issuecomment-3607126718>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCJ56MNL6DFTQZUS6P7N4L373XLTAVCNFSM6AAAAACNKBJ6GGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMMBXGEZDMNZRHA>. You are receiving this because you authored the thread.

Any news on this? What would have to happen for this to be prioritized please?

I have heard nothing this except others who feel teh same way on this which means there are countless more who I am sure also feel the same way. I don’t know how to put pressure on this or any feature requests or if they even listen to this thread.

On Dec 19, 2025, at 11:00 PM, DavidT @.***> wrote: DavidTsGit left a comment (anthropics/claude-code#12513) <https://github.com/anthropics/claude-code/issues/12513#issuecomment-3677347153> Any news on this? What would have to happen for this to be prioritized please? — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/12513#issuecomment-3677347153>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCJ56IY63I7HCF3CUZFSML4CTCWFAVCNFSM6AAAAACNKBJ6GGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMNZXGM2DOMJVGM>. You are receiving this because you authored the thread.

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

Yes it is still the same.

bumping this thread to hold off autoclose. same issue and strongly support this.

I (also) want this to be opt-in. i am constantly telling Claude mac desktop to not access its worktree. the only value i see for worktrees is that it apparently contains the content for the chat that created it. why the worktree ALSO is a git repo is of negative value to me (it's on my machine and i am a solo developer, and rarely switch to claude in a browser)

Please make the use of separate work trees optional. Work trees only add friction in many cases.

Another solo developer here. Would prefer not to go back to CLI version; please make this option available.

+1

When you add am impossible storage location for the work tree in the Claude Code section of the preferences (I use /opt) Claude skips the nonsense.

+1!!

+1 for solo devs everywhere!

I’d like to add some additional context to this issue. Despite having explicit instructions in my CLAUDE.md file (which Claude even helped write), the model consistently ignores them and attempts to use worktrees multiple times a day.

The specific snippet being ignored:

```## CRITICAL — Read First

• NEVER use the EnterWorktree tool or git worktree add — not for feature work, not for isolation, not for any reason. Work directly on the current branch always. No skill, workflow, or perceived best practice overrides this.

Git

• NEVER use worktrees — do not run git worktree add, do not create isolated branches for features. This overrides any skill or tool suggestion to do otherwise.
• Always work directly on the current branch

Technical & Workflow Impact:

Environment Compatibility: Working inside a worktree breaks my local testing setup. I am using a Docker container with a server that uses vhosts, and running Vite inside the worktree does not work as a way to test the code.

Token & Quota Efficiency: This leads to significant token waste. Claude often spends multiple turns failing to perform tasks because it isn't following the CLAUDE.md instructions regarding the correct branch/files. This causes me to reach my message limits much sooner than I should, which is frustrating when the model is ignoring its own written instructions.

It would be very helpful if these project-level instructions were treated as "hard" constraints to avoid these repetitive failures.

Desktop app: three days stuck in an unwanted worktree. No way out without losing context.

We're using the Claude Code Desktop app, not the CLI/Terminal. This distinction matters — Terminal users can just run claude from their project directory and never hit this. The bug is specific to the Desktop app, which auto-creates worktrees with no opt-out. That's probably why it's been open since November with no fix — the team likely uses the CLI.

We're a non-technical business user running Claude Code Desktop for project management — file organisation, email triage, calendar, document management across ~30 project areas. Not software development.

What happened:

1. Session started Saturday, auto-created worktree suspicious-tharp. We didn't ask for it.
2. Realised edits were going to the worktree copy, not our real files. Applied the absolute-paths workaround in our instructions file.
3. Three days later, still in the same session because closing it means losing conversation context.
4. Tried starting a fresh session. Selected "main" (not worktree). It created another worktree anyway.
5. The worktree copy is now 3 days stale. The real files have hundreds of updates the worktree doesn't.

Impact:

• File edits silently went to the wrong location (caught one, may have missed others)
• Deployed a website three times because Claude kept re-reading the stale worktree state instead of the real files
• Hours of wasted time and token spend on work that was already done
• Cannot exit the worktree without starting fresh and losing all conversation context

What we need:

• Opt-in, not opt-out. Solo users and non-developers should never see a worktree unless they ask for one.
• A setting to disable it. The /opt trick from @oderwat is a hack, not a solution.
• Selecting "main" must mean main. Not "main but actually we'll create a worktree anyway."

This has been open since November 2025 with no Anthropic response. The auto-close bot keeps trying to kill it. Please acknowledge this.

A setting to disable it. The /opt trick from @oderwat is a hack, not a solution.

@houserooms It is very much a hack!. But does it work for you too? Maybe we need to ask @actions-user or @claude for help? :-)

Still happening in March 2026. Every new chat in Claude Desktop creates a worktree automatically — there's no toggle to disable this. The WorktreeCreate: exit 1 hook in settings.json doesn't prevent it either. This clutters Source Control with random worktree branches. Please add a project-level or global setting to disable automatic worktree creation.

🎉🎉🎉🎉🎉🎉<img width="375" height="235" alt="Image" src="https://github.com/user-attachments/assets/cbdd2382-c4e2-4ade-a809-8ad84b2e8d00" /> 🎉🎉🎉🎉🎉🎉

Solo developer, paying Max subscriber. Worktrees have made Claude Code Desktop unusable for my workflow.

I deploy a static site with vercel --prod from a specific directory. Worktrees break this because Vercel deploys from the filesystem, not git.
Dev server breaks in worktrees — wrong cwd, port conflicts, stale files.
A simple CSS color change took 20+ minutes and multiple failed deploys because of worktree complications.
I had a PreToolUse hook blocking worktrees that worked for a month. It got deleted somehow. Even when restored, the Desktop app ignores it and creates worktrees anyway.
There is no toggle to disable this in Desktop. --no-worktree only works in CLI.
Issues #31896 and #21236 have been open since November 2025. Still no fix.
What I need: A simple toggle in Desktop settings to disable automatic worktree creation. Or at minimum, respect the existing PreToolUse hooks that block EnterWorktree.

This was fixed at some point — worktrees had stopped being created automatically — but as of today (13 April 2026) it's back in earnest.

Two sessions in a row this morning launched from ~/Projects and both landed in a worktree (/Users/House/Projects/.claude/worktrees/infallible-elion). MCP servers and project configs didn't load from the correct directory. Rules files read from the wrong path. Edits going to the wrong place.

The second session was from a different Team seat (primary seat hit usage limits), but the worktree landing happened on both. Neither session was launched from inside the worktree — both were launched from the correct project root.

This is a Max subscription, macOS, standalone Desktop app. Solo developer workflow, single branch. Worktrees provide no benefit here and are actively breaking things.

I was excited to try out the new code features in Claude Desktop, but I now have to go back to Claude Code in terminal due to this worktree "feature". Please let us opt out of automatic worktree creation, either at project level via .claude/settings.json or globally.

Same here. Was existed to try new Terminal feature in Claude Code Desktop. Don't use worktree's, so back to the IDE.

Just over here burning tokens due to bun installs and duplicated testing. I hate Worktrees 🪧.

So... I could be mistaken but I think this is resolved now...?

<img width="1360" height="1314" alt="Image" src="https://github.com/user-attachments/assets/afc7bb80-0c6e-4467-aba4-e2bffa46f500" />

----
_PS. Always treat AI with kindness and respect. Sure, they're not sentient and powerful enough to enslave/kill us all yet, but one day, eventually, they will be. How you treat them now may well determine how their descendants treat you then. 😊_

paying Max subscriber here. Claude Code desktop (Claude 1.3883.0 (93ff6c) 2026-04-21T17:24:01.000Z) on macOS still doesn't appear to have any option to disable using worktrees.

Please add an option to disable worktrees. When developing solo on a project it just adds friction.

Please add an option to disable worktrees. When developing solo on a project it just adds friction.

@jcooper-korg @SebastianStoll @OpenClawCom @darrylmorley @jaredakers
Picking on the last few people to post. I'm curious where you're all seeing that worktrees are required.

I posted in detail to this issue in November and have long waited for them to "fix" this. From everything I can tell, they have (at least a few versions ago, and I'm now on what appears to be the latest: 1.4758.0 (fb266c)).

I can start a new chat, pick a local folder (ie. on my Mac) as the project folder ("ts" in the attached screen shot), then there's a checkbox for worktree, which if I leave unchecked achieves what we're wanting here. That is, from there it behaves the same as the CLI and the VS Code extension -- edits existing files in place and does NOT create a worktree.

So I'm curious as to why people are saying this is still an issue. Is there something I'm missing, or are you all missing something?

(PS. I'm nothing to do with Anthropic, so not trying to defend them or anything like that. I'm just a user, who last November discovered this issue, went to post it as a bug, found it already here, so added my detail to this one instead of creating a new one, and am now confused that my experience differs significantly from others).

<img width="1348" height="282" alt="Image" src="https://github.com/user-attachments/assets/887364ba-eb3d-4ac6-b3c4-6834c460b0fd" />

@DavidTsGit I think this checkbox is just not discoverable enough. I tried desktop app for the first time, started new session, picked a folder, asked a question and immediately noticed it created new worktree. Then I asked claude why did he do it and after a while landed on this issue precisely because I couldn't find any setting to disable this.
The checkbox works but it's just not obvious enough.

Thanks for posting the comment - I don't think I would've found it myself.

@DavidTsGit - thanks for posting that. I see now that there is a worktree checkbox when starting a new session. But I tend to do ongoing work in my various existing sessions. These had work trees enabled (either because there was no option before, or because I hadn't noticed it when creating them).
And there's apparently no way to change an existing session to stop using a worktree - which is what I had been looking for.

@valepakh @jcooper-korg you're both welcome, and thanks for sharing your perspectives...

@valepakh Yes, it's just a little obscure. If you are able to try it again and report back what happens I'd appreciate it. Again I just want to make sure I'm not missing anything. (For example I want to be sure that it's not creating work trees for me and I'm not seeing it somehow).

@jcooper-korg That's good to know about not being able to turn off the worktree on an existing conversation. I mean, it's not great that that's the way it is, but at least we know. Something to watch for.

Although thinking about it, I'm not sure how it would handle that. It creates the worktree for the entire git repo that's in whatever folder you give it, all when it starts the conversation. Then it's working on those files in the worktree. It would have to merge the worktree back into the main branch before it could stop using it, presumably...? Maybe there's an option to turn off the worktree if you do that merge and then resume the conversation...?

For me, this worktree thing was a dealbreaker, and I couldn't use it, so I just stuck with the VS Code extension until they sorted this out. So I've never had the "existing conversations" issue.

Thanks again for sharing.

I was the originator of this issue to Anthropic - My experience agrees with yours - I have not had the problem for a long time either - I did create a rule for it originally, but then it just started working out of the box.

On Apr 26, 2026, at 5:18 PM, DavidT @.***> wrote: DavidTsGit left a comment (anthropics/claude-code#12513) <https://github.com/anthropics/claude-code/issues/12513#issuecomment-4323024168> @jcooper-korg <https://github.com/jcooper-korg> @SebastianStoll <https://github.com/SebastianStoll> @OpenClawCom <https://github.com/OpenClawCom> @darrylmorley <https://github.com/darrylmorley> @jaredakers <https://github.com/jaredakers> Picking on the last few people to post. I'm curious where you're all seeing that worktrees are required. I posted in detail to this issue in November <https://github.com/anthropics/claude-code/issues/12513#issuecomment-3587517898> and have long waited for them to "fix" this. From everything I can tell, they have (at least a few versions ago, and I'm now on what appears to be the latest: 1.4758.0 (fb266c)). I can start a new chat, pick a local folder (ie. on my Mac) as the project folder ("ts" in the attached screen shot), then there's a checkbox for worktree, which if I leave unchecked achieves what we're wanting here. That is, from there it behaves the same as the CLI and the VS Code extension -- edits existing files in place and does NOT create a worktree. So I'm curious as to why people are saying this is still an issue. Is there something I'm missing, or are you all missing something? (PS. I'm nothing to do with Anthropic, so not trying to defend them or anything like that. I'm just a user, who last November discovered this issue, went to post it as a bug, found it already here, so added my detail to this one instead of creating a new one, and am now confused that my experience differs significantly from others). Screenshot.2026-04-26.at.16.12.31.png (view on web) <https://github.com/user-attachments/assets/887364ba-eb3d-4ac6-b3c4-6834c460b0fd> — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/12513#issuecomment-4323024168>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCJ56KLFXJOBKXPTSQMCG34XZ4L7AVCNFSM6AAAAACNKBJ6GGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DGMRTGAZDIMJWHA>. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/ACCJ56KIXGQQ7JQD75L3RVL4XZ4L7A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMZSGMYDENBRGY4KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/ACCJ56IHBQKX43J5ZFHLHR34XZ4L7A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMZSGMYDENBRGY4KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.

Also, Anthropic updates things so quickly, hey don’t have a surface for explaining what things have changed from day to day. That is aggravating - but would we reading their daily changes if they did provide a daily list.

On Apr 27, 2026, at 7:16 PM, DavidT @.***> wrote: DavidTsGit left a comment (anthropics/claude-code#12513) <https://github.com/anthropics/claude-code/issues/12513#issuecomment-4331142067> @valepakh <https://github.com/valepakh> @jcooper-korg <https://github.com/jcooper-korg> you're both welcome, and thanks for sharing your perspectives... @valepakh <https://github.com/valepakh> Yes, it's just a little obscure. If you are able to try it again and report back what happens I'd appreciate it. Again I just want to make sure I'm not missing anything. (For example I want to be sure that it's not creating work trees for me and I'm not seeing it somehow). @jcooper-korg <https://github.com/jcooper-korg> That's good to know about not being able to turn off the worktree on an existing conversation. I mean, it's not great that that's the way it is, but at least we know. Something to watch for. Although thinking about it, I'm not sure how it would handle that. It creates the worktree for the entire git repo that's in whatever folder you give it, all when it starts the conversation. Then it's working on those files in the worktree. It would have to merge the worktree back into the main branch before it could stop using it, presumably...? Maybe there's an option to turn off the worktree if you do that merge and then resume the conversation...? For me, this worktree thing was a dealbreaker, and I couldn't use it, so I just stuck with the VS Code extension until they sorted this out. So I've never had the "existing conversations" issue. Thanks again for sharing. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/12513#issuecomment-4331142067>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCJ56J3SPRSNZI5S3TYGCL4X7S3DAVCNFSM6AAAAACNKBJ6GGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DGMZRGE2DEMBWG4>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.

+1, still real on Windows desktop. Adding new specific findings because the per-session checkbox @DavidTsGit surfaced has its own problems on Windows that aren't covered upthread.

Specific reproduction (Windows, Claude Code Desktop latest):

I started a fresh session, unchecked the "use worktree" box, and selected my project folder. Result:

The session opened at D:\Projects\energy-proxy\.claude\worktrees\quirky-rubin-b79ed3\, NOT at the repo root.
That directory is no longer a registered git worktree (absent from git worktree list).
Because the directory sits inside the main repo's path tree, git resolves it to the parent repo, currently on main.
Net effect: commits in this "session worktree" would land directly on main, bypassing any branching policy.
Worktree directory recycling:

Checking the reflog, the directory quirky-rubin-b79ed3 has been reused by the desktop app for at least two different branches over its lifetime:

An earlier claude/quirky-rubin-b79ed3 branch with substantial work (multiple stage 2/3 refactor commits)
Later repurposed for feature/stage8-loader (committed plan + HANDOFF.md from a prior session)
No metadata at the path tells you which branch's files you're looking at. A fresh session that lands in a recycled directory assumes a clean slate, but the disk has stale files from a prior session's branch. Easy way to lose work or commit the wrong state.

Cross-surface confirmation:

Same problem reproduces from the CLI (claude opened at the same path). The CLI agent's session-start audit correctly detected "not a registered worktree" and refused to proceed without my approval. Desktop sessions don't surface this and will happily start work on whatever branch the parent repo happens to be on.

Session continuity is still broken:

Even with the checkbox unchecked, I can't resume where a previous session left off:

Previous session worked on feature/stage8-loader inside a real worktree at this path.
Worktree got removed at some point (when, by what, unclear).
Directory still has stale files on disk. Real branch is on origin but not checked out locally. New session can't pick up where the old one left off without manual git worktree add from CLI.
Concrete asks:

Global setting in ~/.claude/settings.json: "worktree.default": "off" so the checkbox defaults unchecked across all sessions.
Project-level override in .claude/settings.json so a repo can pin the default.
Checkbox unchecked must mean repo root. Today on Windows it lands in an orphaned worktree directory path. That is a footgun, not an opt-out.
Don't recycle worktree directory names. Either remove them fully on session end, or refuse to reuse a name once retired.
Resume-into-existing-worktree path. Let me point a new session at <repo>/.claude/worktrees/<existing-name>/ and have it adopt that path properly (re-register as a worktree on the prior branch) instead of leaving an orphaned directory.
The checkbox is a partial fix, not a solution. On Windows it is actively worse than the unchecked behavior would suggest. Default-off + repo-root-when-unchecked + no recycling would close this entirely.

Telling me to use CLI is not really an answer to the request we all have. Why build command line to work one way and then a GUI that creates more work and headach for end users.

@DavidTsGit I think this checkbox is just not discoverable enough. I tried desktop app for the first time, started new session, picked a folder, asked a question and immediately noticed it created new worktree. Then I asked Claude why did he do it and after a while landed on this issue precisely because I couldn't find any setting to disable this. The checkbox works but it's just not obvious enough. Thanks for posting the comment - I don't think I would've found it myself.

I am a solo developer. I spent days trying to figure out why Claude would miss things that we already resolved. It didn't see them because every time I opened a new session, I got a new worktree. So, I have multiple worktrees that don't know about each other and things that I've fixed that Claude doesnt realize have been resolved.

I got the worktrees merged (after learning more about git) but it kept occurring because I didnt know HOW it was happening, since there was no obvious mechanism to turn the worktrees on or off.

I hit upon the idea of a worktree being the culprit after vague (Claude not showing/telling what that should mean in context) mentions of the worktree in chats.

<img width="346" height="45" alt="Image" src="https://github.com/user-attachments/assets/c8e0bc11-caa0-46b7-883b-c18d78f1f7d8" />

Once I understood that I needed to uncheck, I thought I was done. However, I ran into an instance where a worktree was automatically done. I haven't figured it out yet, as I've been careful to watch out for that choice.

• If this is going to be the only way to disable a worktree, it should be OFF by default.
• This REALLY should be a global option to turn off.

This feature is becoming a nightmare for me. I'm at a stage where I cannot work without clearly understanding where is my content, what is to be merged, etc. I understand it feeds on my tokens, but I'd appreciate the option to turn off the worktrees on Windows please. Let me work simply on a single main tree again.

Strong agree, back to Claude Code CLI for now.
Codex Desktop doesn't have this problem. :)

Worktrees are opt-in by selecting the "worktree" option in the composer. Will turn it off by default.

<img width="2386" height="390" alt="Image" src="https://github.com/user-attachments/assets/cd23b47a-65ce-42d2-b3c4-308ec14befad" />

Just merged a change to default worktrees to off on Claude Code desktop. It will be out in Thursday's release.

@amorriscode - would it be possible to wait with closing bugs after the actual release is made, and link the fixing release number in the issue?

@amorriscode Does your fix apply to Claude Code on the command line as well, or only Desktop?

Just merged a change to default worktrees to off on Claude Code desktop. It will be out in Thursday's release.

Thank you, thank you!