iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Sometimes. Claude Code’s current documentation says it automatically removes a clean Git worktree it created when you exit an unnamed interactive session. A named session prompts first, and changes or uncertainty about the worktree’s state also trigger a prompt. Git documents git worktree lock as protection against automatic pruning and ordinary Git removal—but Claude Code’s interactive-exit documentation does not explicitly say that a user-set lock prevents its cleanup decision. If the worktree matters, choose Keep at Claude’s prompt when offered, and don’t rely on a lock as your only safeguard without confirming the behavior in your installed version.
When does Claude Code remove a worktree on exit?
The automatic-removal rule is narrower than “Claude deletes every clean worktree.” According to Anthropic’s worktree documentation, it applies to a clean Git worktree that Claude Code created when you leave an unnamed interactive session.
| Session or worktree state | Documented exit behavior |
|---|---|
| Unnamed interactive session; Claude-created Git worktree is clean | Claude Code removes the worktree and its branch automatically. |
| Named interactive session | Claude prompts before removing the worktree. |
| Worktree has changes, untracked files, uncommitted work in a checked-out submodule, or new commits | Claude prompts you to keep or remove it. |
| Claude cannot verify the worktree’s state | Claude prompts rather than removing it automatically. |
Noninteractive -p run |
There is no exit prompt, and Claude does not clean up the worktree at exit. |
These are Claude Code behaviors, not general rules for every Git worktree. A worktree you created yourself with git worktree add is excluded from Claude’s documented periodic retention sweep, even if you later use it with --worktree and background the session. For a custom WorktreeCreate hook, Claude’s documentation points to the corresponding WorktreeRemove hook behavior.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsWhat does git worktree lock actually protect?
Git’s worktree manual says locking prevents a worktree from being automatically pruned and “also prevents it from being moved or deleted.” Ordinary git worktree remove removes only a clean worktree; Git documents --force for removing an unclean one.
#1 Best Overall
That Git guarantee should not be overstated as a Claude Code guarantee. The current Claude Code section describing interactive exit cleanup does not explicitly say whether its cleanup path honors a lock that you set yourself. The two documents establish Git’s intended lock protection and Claude’s cleanup rules, but do not expressly connect those rules for every interactive exit path. Confirm the behavior on your installed Claude Code version before treating the lock as your sole protection.
How to keep a worktree you may need later
- If Claude offers a Keep choice, select it. The interactive prompt is the clearest documented way to preserve a worktree when Claude asks what to do.
- For Git-level protection, lock the worktree:
git worktree lock --reason "keep for later" /path/to/worktree. Use the path to the worktree directory. The reason is optional; checkgit worktree lock -hif your installed Git version uses different command help or options. - Check that Git registered the lock: run
git worktree list --verboseand look for the locked annotation on the intended worktree. - Keep another copy of important work. Until you have confirmed how your Claude Code version handles a user-set lock at interactive exit, do not make the lock your only safeguard for valuable changes.
A Git lock is not a backup, and it does not prevent you or another process from deleting files outside Git’s worktree operations.
Rank #2
When should you unlock or remove the worktree?
Unlock only when you intend to remove the protection. For a worktree locked at /path/to/worktree, run git worktree unlock /path/to/worktree. Unlocking does not itself remove the worktree; it removes the lock. Then, if cleanup is intended, use git worktree remove /path/to/worktree for a clean worktree. Git documents git worktree remove --force /path/to/worktree for an unclean worktree; inspect or preserve its contents first, because forcing removal can discard work.
If Git refuses removal because the worktree is locked, unlock it only after deciding that removal is deliberate. Do not use unlock as a routine troubleshooting step when your goal is to keep the worktree.
Rank #3
- Used Book in Good Condition
How Claude’s later cleanup sweep treats locks
Claude’s documentation distinguishes locks it sets temporarily for background or subagent work from locks set by the user. During its retention sweep, Claude does not release a user-set lock; it releases its own lock after the related session process exits. In a noninteractive -p run, there is no exit cleanup, so a lock set on creation can remain until a later stale-lock sweep. The same documentation says that, before Claude Code v2.1.210, locks left by killed sessions stayed in place until someone ran git worktree unlock. These sweep rules do not establish that a user lock is honored by every interactive exit-cleanup path.
A version-specific report is not a universal rule
A Claude Code issue opened September 6, 2026 reports ten clean-exit tests on Claude Code 2.1.261 on macOS in which an adopted, pre-existing worktree directory disappeared without a prompt while its branch remained. That is a report about one version and setup, not an official general guarantee; it is a reason to verify behavior if you depend on an adopted worktree. See Claude Code issue #92425.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
