Claude Code Deletes Git Worktrees and Branches Without Warning

The Problem: Unannounced Worktree Deletion

Developers using Claude Code with the --worktree option face a potentially destructive behavior: upon exiting a session with no uncommitted changes or new commits, Claude Code automatically deletes the worktree. More critically, it also removes the associated Git branch. This happens without any user confirmation dialog, presenting a significant risk of data loss for developers who aren't aware of this behavior.

This is not a bug. The documentation confirms this is the intended functionality. There is currently no setting within Claude Code to disable this automatic cleanup. The tool assumes that a clean worktree upon exit signifies it's no longer needed and proceeds to prune it, along with its branch, to maintain a tidy workspace.

The issue was tested on Claude Code version 2.1.263, Git version 2.52.0, running on macOS. The behavior persists even if the worktree was pre-created using git worktree add. If the branch follows Claude Code's naming convention, such as worktree-<name>, then existing unmerged commits on that branch are also subject to forceful deletion.

How Claude Code Manages Worktrees

Claude Code manages its worktrees using Git's built-in worktree locking mechanism. When Claude Code creates or operates on a worktree, it places its own lock file. This lock is formatted in a specific way that Claude Code recognizes. When the application exits, it checks for these locks. If the worktree is clean (no uncommitted changes, no new commits), and the lock matches Claude Code's expected format, the tool proceeds with deletion. The logic is that if Claude Code is the sole active user and the worktree is in a stable state, it can be safely removed.

The default behavior is to remove both the worktree directory and the Git branch it points to. This aggressive cleanup is designed to prevent stale worktrees from accumulating, but it lacks the safeguards that users typically expect when dealing with development environments and version control. Developers accustomed to Git's more cautious approach, which usually prompts for confirmation or requires explicit commands for deletion, can be caught off guard.

The Solution: Git Worktree Locks

The key to preventing Claude Code from deleting your worktrees lies in interfering with its lock release mechanism. Claude Code only releases locks that match its specific format. By re-acquiring the lock on the worktree with your own reason, you signal to Claude Code that the worktree is still in use or managed by another process. This prevents Claude Code from proceeding with the automatic deletion.

The simplest way to achieve this is to manually re-lock the worktree before exiting Claude Code. You can do this from your terminal using the command:

git worktree lock --reason "My reason for keeping this worktree" <path-to-worktree>

Replace <path-to-worktree> with the actual path to the worktree directory managed by Claude Code. The --reason flag is crucial; it adds a custom identifier that Claude Code will not recognize as its own, thus preventing its automatic cleanup routine from touching the worktree.

Automating Protection with Session Hooks

For developers who frequently use Claude Code with worktrees and want a more seamless experience, a SessionStart hook can automate the re-locking process. This hook can be configured to run automatically whenever a new Claude Code session begins. The hook would execute the git worktree lock command with a custom reason, ensuring that any worktree opened by Claude Code is immediately protected from accidental deletion upon session exit.

Implementing a hook requires understanding your shell's configuration and how Claude Code integrates with it. Typically, you would add the command to a script that is sourced by your shell's startup files (like .bashrc, .zshrc) or directly within Claude Code's extension settings if it supports custom hooks. The hook needs to identify the worktree path being used by the current Claude Code session and apply the lock. This proactive measure ensures that developers can work with Claude Code without the constant fear of losing their work due to an unannounced cleanup.

Understanding the Implications

The core issue stems from a mismatch in assumptions between Claude Code's design and typical developer workflows. While the tool aims for efficiency by cleaning up, it overlooks the critical nature of development branches and the importance of explicit user control over version control operations. Developers often maintain branches with unpushed commits for various reasons, including staging, experimental features, or simply as a backup.

The fact that the associated Git branch is also deleted is particularly concerning. This means that even if the worktree directory itself could be recovered, the commit history that was unmerged or not yet pushed could be lost. This behavior is akin to a destructive operation that bypasses standard Git safety nets. For teams using collaborative workflows, this could lead to significant disruptions if a developer inadvertently loses work that was critical for a feature or bug fix.

The git worktree lock command, while effective, requires users to be aware of its existence and purpose. It's a lower-level Git feature that many developers might not be familiar with, especially those new to Git or working primarily within IDEs that abstract away such details. This reliance on a less common Git command as the primary defense mechanism highlights a gap in Claude Code's user experience and safety features. It places the onus on the user to understand and implement a workaround for a behavior that, while documented, is highly counterintuitive and potentially damaging.

Looking Ahead

The current solution relies on a workaround that leverages a specific Git feature. Ideally, Claude Code would offer a configuration option to disable the auto-deletion of clean worktrees. Alternatively, it could implement a confirmation dialog, similar to how many IDEs handle file deletions, providing users with a clear choice before any data is removed. Until such changes are made, developers must remain vigilant and ensure they have implemented protective measures, such as the worktree lock, to safeguard their work.

The broader implication for tools that interact with Git worktrees is the need for robust safety mechanisms. Developers expect their tools to respect the integrity of their version control history. Any tool that performs automatic, unprompted deletions of branches or commits risks eroding trust and causing significant disruption. The Claude Code situation serves as a reminder that convenience should not come at the expense of data safety, especially in the sensitive domain of software development.