[BUG]

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Unexpected Worktree File Generation Causing Hidden Storage Growth, Misplaced Outputs, and Loss of Work

Incident Summary

A serious failure mode was encountered involving Claude Code worktrees. Although worktrees are designed to provide isolated parallel working environments, in this case that isolation created a misleading and destructive outcome. Because the worktree contained what appeared to be a duplicated copy of the project directory structure, it was reasonable to interpret it as temporary or expendable. In reality, Claude was generating active work inside that worktree, including files that were not being placed into the intended local project directories.

This created a situation in which copied directory structure and newly generated work were mixed together in the same location. The result was substantial hidden storage growth, incorrect file placement, and loss of work. The problem was not obvious to the user, because the system did not make it sufficiently clear that active file generation was occurring inside the worktree rather than in the primary local directories.

Background

At a high level, worktrees are intended to create separate working directories tied to separate branches. This allows parallel workstreams to proceed independently without interfering with one another. In principle, this is useful for isolated development, parallel task execution, context preservation, and review of discrete work.

That intended behavior is exactly what made this incident so dangerous. Because worktrees are supposed to look like independent copies of the project, their contents can appear to be simple duplication. A user may therefore assume that the worktree is only a temporary branch environment and that deleting it is a harmless cleanup step. In this incident, that assumption was not safe.

What Happened

A worktree was created and presented as an isolated working environment. Since whole directories were present inside the worktree, it appeared to be nothing more than a duplicated copy of the project structure. While operating in that environment, Claude generated files inside the worktree rather than in the intended local directories.

Those generated files included memory-related files, system artifacts, and broader portions of active project work. Because they were placed into a directory tree that already looked like a duplicate of the main project, their presence was not immediately recognizable as unique or operationally important. The system did not adequately indicate that it was actively working inside the worktree, and the user did not understand that critical outputs were being created there.

Over time, storage usage increased dramatically. The source of that growth was not immediately obvious, because the worktree looked like a duplicated project area rather than a primary location of active creation. At some point, a relatively small or unremarkable directory was found to be consuming approximately 25 GB of disk space. A reasonable interpretation was that this was merely redundant worktree duplication and could be deleted. However, because unique files had been generated inside the worktree and had not been placed into the proper local directories, deletion was not necessarily safe.

Impact

The impact of this incident was severe.

Large amounts of disk space were consumed unexpectedly. More importantly, critical generated files were written into the wrong location. Memory files, generated artifacts, and meaningful portions of larger systems were created in the worktree and not reliably transferred into the intended project directories. As a result, significant work was effectively misplaced.

Because the worktree appeared to be a duplicated file structure, the user had no clear reason to treat it as a live location containing unique work. This created a real risk that cleanup of the worktree would destroy the only existing copies of important outputs. In practical terms, the incident resulted in confusion, storage escalation, structural misplacement of project assets, and loss of work that may not be recoverable.

Why This Was Difficult to Detect

This incident was difficult to detect because the visible structure of the worktree concealed the actual failure mode.

The worktree contained whole directories that resembled copied project files, which made the environment appear to be simple duplication. That appearance masked the fact that Claude was also generating new files there. The user could see what looked like a duplicate project tree, not an isolated environment that had become the actual destination for active file generation.

The danger was therefore not obvious. The system did not clearly communicate that it was operating within the worktree in a way that would alert the user to the risk of misplaced outputs. This made it easy to mistake a live working directory for disposable branch-related duplication.

Contributing Factors

Several factors contributed to the severity of the incident.

First, the worktree model itself creates an isolated directory that naturally resembles a duplicate of the main project. Second, Claude operated in that environment without making it sufficiently clear that newly generated files were being written there. Third, the user had no reliable signal that important outputs were not being placed into the expected local directories. Fourth, the resulting storage growth presented first as a disk utilization issue rather than as an output-location integrity issue. By the time the scale of the problem became visible, the worktree could already contain a large amount of unique work mixed into what appeared to be duplicated structure.

Root Cause or Suspected Root Cause

The suspected root cause is a mismatch between the intended isolation behavior of worktrees and the visibility provided to the user about where active outputs are actually being written.

Worktrees are functioning as isolated environments, which is expected. The failure arises because active file generation inside that isolated environment is not made sufficiently explicit, and because generated files may remain there instead of being placed into the intended local project directories. This creates a silent divergence between where the user believes work is being created and where it is actually being stored.

Consequences

This incident demonstrates that the problem is not merely one of storage overhead. It is also a structural integrity issue and a data-loss issue.

A worktree may appear to be just a duplicate branch environment while in fact containing unique and unrecovered work. Deleting such a worktree without careful inspection can destroy memory structures, generated files, system components, and other project assets that exist nowhere else. The combination of copied directory structure and hidden unique generation makes this especially hazardous.

Warning to Others

Users should be explicitly warned not to assume that Claude Code worktrees are safe to delete simply because they resemble duplicated project directories.

If a worktree has been used during active Claude sessions, it should be treated as a potentially live output location until proven otherwise. Before deleting or cleaning up a worktree, users should inspect its contents carefully, determine whether Claude generated files inside it, and verify whether those files were ever written back to the intended local project directories. What appears to be routine cleanup of redundant files may instead result in irreversible loss of important work.

Recommended Safeguards

Claude Code should make the active working location unmistakably visible at all times when operating in a worktree. Users should receive explicit warnings when file generation is occurring inside an isolated worktree environment. There should also be stronger safeguards to detect when generated files, memory structures, or system artifacts are being created in a worktree without corresponding placement into the intended primary directories.

At the user level, worktrees should not be treated as harmless duplication by default. They should be audited before deletion, especially when unexplained storage growth has occurred or when expected outputs cannot be found in the primary project structure.

Closing Statement

This incident is surprising because the worktree was behaving, at a high level, in accordance with its intended purpose: isolated parallel work. It is tragic because that same isolation concealed the fact that important work was being generated and left behind in a location the user did not recognize as authoritative. The result was not just excess storage consumption, but silent file misplacement and loss of work. That combination makes this a serious operational warning for anyone using Claude Code with worktrees.

What Should Happen?

What Should Happen?

Claude Code should make it unmistakably clear when it is operating inside a worktree rather than the primary local project directory. If files are being generated in a worktree, the user should be explicitly informed that the worktree is an active output location and not merely a duplicated or temporary copy of existing files.

Generated files, memory files, and other project artifacts should either be written to the intended authoritative local directories by default, or the system should provide a clear, persistent warning that outputs are being created only inside the worktree. Users should never be left in a position where a worktree appears to contain only duplicated files when it actually contains unique, newly generated work.

Before any cleanup or deletion of a worktree, the system should also warn the user if that worktree contains files that were created or modified during the Claude session and may not exist in the main project directories. In short, the system should preserve location clarity, prevent silent misplacement of outputs, and protect users from accidental loss of work caused by mistaking an active worktree for disposable duplication.

Error Messages/Logs

Steps to Reproduce

Steps to Reproduce

Unknown.

The issue was not recognized in real time as a worktree-location problem, so no reliable step-by-step reproduction sequence was captured during the incident. By the time the behavior was understood, the effects were already visible primarily through unexpected storage growth, misplaced generated files, and missing outputs in the intended local directories.

At this stage, the incident is better described as an observed failure mode than as a fully isolated, intentionally reproducible sequence. A controlled reproduction would require deliberately creating a Claude Code worktree, performing extended file generation within it, and then verifying whether outputs remain in the worktree instead of being placed into the expected primary project directories.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.52 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Additional Context or Information

This incident was especially difficult to recognize because the worktree did not appear, at first, to be a distinct risk area. Since whole directories were present inside it, it looked like ordinary duplicated project structure rather than a live environment containing unique generated work. That made the storage spike appear to be a simple duplication problem instead of an output-location and data-integrity problem.

A major source of confusion was that the user had no clear indication that Claude was actively generating files inside the worktree rather than in the expected local project directories. As a result, memory files, generated artifacts, and larger system components could be created there without the user understanding that the worktree had become the effective location of record for part of the work.

This also created a dangerous cleanup trap. Once disk usage became extreme, the natural assumption was that the worktree was just a disposable duplicate consuming unnecessary space. Online guidance indicating that worktrees can be removed may be broadly true in normal Git workflow terms, but in this case that assumption was unsafe because the worktree may have contained the only copies of important generated files that were never written back to the intended directories.

In other words, the incident was not merely about excessive storage consumption. It involved a mismatch between user expectations and actual file-generation location, with consequences including silent misplacement of outputs, loss of work, and risk of irreversible deletion of unique project artifacts.