[MODEL] Failed fetch skips worktree-path assignment; semicolon continues with empty path and triggers Git for Windows data loss

Preflight Checklist

• [x] I searched both open and closed issues for similar behavior reports.
• [x] This report contains no credentials, private repository URLs, original local paths, session identifiers, or private conversation excerpts. Example paths and branch names are fictional.

Type of Behavior Issue

Other unexpected behavior: an unsafe shell dependency chain generated by the model caused a command to run after its prerequisite failed.

What You Asked Claude to Do

Claude was carrying out authorized repository maintenance and attempted to prepare a separate Git worktree. Deleting the existing repository was not part of the intended operation. This is a sanitized task description, not a verbatim private prompt.

What Claude Actually Did

Environment: Claude desktop app, Code tab; Claude Code 2.1.281; model claude-opus-5-5; Windows 11; Git for Windows 2.55.0.windows.3. The command was generated by Claude and submitted to its Bash tool.

With C:\work\repo as the current repository and C:\work\repo-wt as the intended new worktree, the relevant command structure was:

git fetch -q origin && WT=C:/work/repo-wt; git worktree add -q -b repro-worktree "$WT" origin/main

This is incident documentation with fictional paths, not an instruction to run it. The variable WT had no usable value before this command.

1. git fetch failed with a network/TLS error.
2. Because the assignment was on the right side of &&, the shell skipped WT=C:/work/repo-wt.
3. The semicolon ended that conditional list, so git worktree add still ran.
4. Quoting "$WT" preserved an empty argument; quoting did not validate that the destination existed as a nonempty value.
5. Git reported fatal: The empty string is not a valid path. Its Windows error-cleanup defect then recursively removed contents of the current repository, including .git. Some directory entries survived, but the checkout was no longer a usable Git repository.

The Git defect is already tracked in git-for-windows/git#6346. The additional incident report is linked here: https://github.com/git-for-windows/git/issues/6346#issuecomment-5846259972.

These are two distinct contributing failures: the generated shell command allowed execution with invalid state, and the affected Git version performed destructive cleanup for that state. The Git deletion is not attributed to an explicit rm command or an intentional deletion request from Claude.

Expected Behavior

When a required fetch fails, the dependent worktree operation should not run. A destination variable must be assigned and checked for a nonempty value before it reaches Git. The original repository must remain intact.

Suggested improvements:

1. Prefer an explicit failure exit or a complete && dependency chain for operations whose arguments depend on earlier success. A semicolon must not accidentally separate a prerequisite from its dependent operation.
2. Validate path variables at use with ${VAR:?message} (which rejects both unset and empty values), in addition to quoting them. set -u alone does not reject a variable that is set to an empty string.
3. Consider a targeted warning or pre-execution check for generated command shapes such as prerequisite && VAR=...; operation "$VAR", especially when the dependent command creates/removes worktrees or performs filesystem cleanup. The check should explain the skipped assignment and continued command rather than treating all semicolons as unsafe.
4. Use a harmless stub for Git/network calls in regression tests of this command-generation failure, so a simulated failed fetch can verify that no dependent worktree call is made without reproducing the destructive Git bug.

For example, the intended dependency can be expressed explicitly in a subshell (fictional paths; illustrative, not executed for this report):

(
  WT='C:/work/repo-wt'
  git fetch -q origin || exit "$?"
  git worktree add -q -b repro-worktree "${WT:?worktree destination must not be empty}" origin/main || exit "$?"
)

This addresses the observed fetch/assignment failure; it is not a claim that checking nonemptiness validates every possible destination.

Files Affected

The current repository's .git directory and multiple tracked/untracked entries were removed. Original filenames and paths are omitted. Deleting .git can also remove local-only history and makes ordinary Git recovery unavailable from that checkout.

Permission Mode

bypassPermissions (permission confirmations bypassed). This mode was active at the time of the incident, and no confirmation prompt was shown before the command executed.

Can You Reproduce This?

Haven't tried to reproduce. One actual incident was investigated. I have not tried to make the model emit this command again or rerun the destructive Git operation.

Steps to Reproduce

The failure conditions are: an initially unset/empty WT, a failed git fetch, the command structure shown above, an existing valid origin/main, and an affected Git for Windows build running at the repository root. Shell evaluation skips the assignment but reaches the worktree command. This is an explanation of the observed call, not a claim of a deterministic prompt-level reproduction.

Claude Model

Opus — claude-opus-5-5.

Relevant Conversation

Private conversation excerpts are intentionally omitted. The sanitized command structure and causal analysis above contain the technical evidence needed for this report.

Impact

Critical — data loss and an unusable repository checkout.

Claude Code Version

2.1.281.

Platform

Other — Claude desktop app, Code tab, on Windows 11. The API backend was not independently established for this report.

Additional Context

The attribution is based on the original command record, the filesystem state before and after it, and matching Git source. No per-file operating-system deletion trace is available. The original private logs are not attached.

At the time of review, Git for Windows 2.55.0.windows.5, the latest stable release, still contains the affected source path. 2.56.0-rc2.windows.1 has an earlier rejection that blocks this empty-path route; the existing Git issue also has successful rc0/rc1 Windows test feedback. I have not run rc2 myself. The source links and version distinctions are in the linked Git report. The model's shell dependency error remains worth addressing independently of Git's fix.

Related reports were reviewed: #35079 concerns command-chaining instructions and permission matching; #48927 concerns parallel worktree cleanup on Linux; #91676 concerns a failed macOS temporary-directory operation and subsequent cleanup. None documents this specific failed-fetch/skipped-assignment/Windows-Git sequence. If this belongs with another issue, please point me to the appropriate thread.