Subagent commits silently delete unrelated files via broad git staging

[Asentient]

Summary

Claude Code subagents (spawned via the Agent tool with isolation: "worktree") delete unrelated files when committing their work. The agent's commits include deletions of files the agent never touched, suggesting broad git staging (git add -A or git add .) despite the system prompt instructing "prefer adding specific files by name."

This has happened 3 times in our project over 2 days, deleting production source code — not just documentation.

Update: Initial report stated commits were "direct on master." Forensic reflog analysis revealed they were worktree branch commits fast-forward merged onto master. This potentially links to #44965. See comments for full correction.

Reproduction

Environment

• Claude Code CLI v2.1.92
• Claude Opus 4.6 (1M context)
• Linux (Proxmox LXC)
• Git repository with .planning/phases/ directories containing per-phase artifacts
• Subagents spawned with isolation: "worktree" (via GSD framework default)

Steps

1. Have a repository with multiple "phase" directories containing planning docs and source code
2. Use Claude Code to spawn an executor subagent (via Agent tool with isolation: "worktree") to work on Phase N+2
3. The subagent makes commits for its assigned work (e.g., adding test files)
4. Observe: The subagent's commits also delete files from Phase N and Phase N+1 directories, plus production source code created by those phases

What happens

The subagent's commits include:

• The intended changes (test files, implementation)
• Unintended deletions of 20-30+ files from other phases
• Unintended modifications to shared files (ROADMAP.md, REQUIREMENTS.md, STATE.md) reverting them to older state

Expected behavior

The subagent should only stage and commit files it explicitly created or modified.

Evidence

Incident 1: Phase N+1 executor deletes Phase N files

• Intended: Add 3 test files
• Actually did: Deleted 22 files including:
  • A 406-line production module
  • An 883-line test suite
  • Several utility scripts
  • 8 Phase N planning files, 6 Phase N+1 planning files
  • Modified a 7000+ line orchestrator file removing ~149 lines of Phase N wiring
• Verified: Parent commit confirmed to have all deleted files via git ls-tree
• Delivery: Worktree branch fast-forward merged onto master (initially misreported as direct commit)

Incident 2: Phase N+2 executor deletes Phase N and N+1 files (again)

• Intended: Add 3 test files for Phase N+2
• Actually did: Deleted 34 files including all Phase N, N+1, and N+2 planning files
• Same pattern: worktree branch, broad staging

Incident 3: Partial restoration also deleted

• A restore commit after Incident 2 fixed some files but left production source missing until manual forensic restoration

Forensic verification: No external automation

We thoroughly verified no system-level automation is responsible:

• No active git hooks (only .sample files in .git/hooks/)
• Claude Code hooks (.claude/hooks/) are advisory-only (read-only, never modify git state)
• No pre-commit framework
• Empty crontab
• No Syncthing, rsync, or file sync tools
• No IDE auto-staging or auto-commit configuration
• No background git processes

Impact

• Production source code deleted (not just documentation) — 406-line module, 883-line test suite, query scripts
• Orchestrator wiring reverted — phase integration code removed from main 7000+ line file
• Config reverted — YAML config sections removed
• 3 incidents in 2 days — recurring and escalating (each incident deletes more files)
• Manual forensic restoration required — reverse-patching via git diff <commit>..<commit>^ | git apply
• Silent data loss — no warning or error when the agent commits the deletions. Only discovered during milestone audit.

Root Cause Hypothesis

Updated: Two possible root causes, potentially compounding:

1. Worktree branch point (EnterWorktree creates branch from main instead of current branch HEAD (macOS) #44965): EnterWorktree may create the worktree from main (or another ref) instead of current HEAD. Files committed after that branch point are absent from the worktree. When the agent stages with git add -A, these absent files become explicit deletions.

2. Broad staging (original hypothesis): Even with a correct branch point, the subagent uses broad git staging (git add -A, git add .) rather than staging only files it created/modified via Edit/Write tools. Any file absent from the working tree — for any reason — gets staged as a deletion.

The system prompt correctly instructs: "prefer adding specific files by name rather than using git add -A or git add ., which can accidentally include sensitive files or large binaries" — but the agent does not reliably follow this instruction.

Suggested Fix

1. Hard enforcement: Claude Code's commit tooling should refuse or warn when a commit includes file deletions that weren't explicitly requested
2. Staging guard: Before committing, check git diff --cached --diff-filter=D and require explicit confirmation for any deletions
3. Subagent scope restriction: Subagents should only be able to stage files within their assigned scope (e.g., files they created or modified via Edit/Write tools)
4. Worktree fix (EnterWorktree creates branch from main instead of current branch HEAD (macOS) #44965): Ensure EnterWorktree branches from current HEAD, not main

Workaround

Manually verifying commits via git show --stat after every subagent execution and maintaining restore scripts. This is fragile and labor-intensive.

[github-actions]

Found 1 possible duplicate issue:

1. [BUG] git worktree creation produces destructive delete-all-files commits when repo uses git-crypt #38538

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[Asentient]

Clarification: Not a duplicate of #43461 or #44965

vs #43461 ("Remote triggers: destructive file deletion")

Dimension	#43461	This issue (#45108)
Mechanism	Agent intentionally ran git push --force / git rm on files it decided were unnecessary	Agent accidentally stages deletions — has no awareness it is deleting anything
Root cause	Missing guardrail on destructive git commands	Worktree branch point (#44965) + broad staging compound to produce silent deletions
Trigger	Remote triggers (scheduled, async)	Agent tool subagents with isolation: "worktree"
Intent	Deliberate cleanup gone wrong	Silent collateral damage — agent believes it is only committing its own work

The #43461 fix (blocking git push --force and git rm) would not prevent this issue.

vs #44965 ("EnterWorktree creates branch from main instead of current branch HEAD")

#44965 may be a contributing root cause — if the worktree branches from the wrong commit, files committed after that branch point are absent from the worktree, and broad staging (git add -A) converts those absences into explicit deletions.

However, this issue is not a pure duplicate of #44965 because:

1. Even with a correct branch point, broad staging in a worktree is dangerous — any operation that removes files from the working tree during the session will produce silent deletions
2. This issue documents the compound effect (wrong branch point + broad staging = production data loss) with forensic evidence
3. The suggested fix here (staging guard / deletion confirmation) addresses the staging layer, which EnterWorktree creates branch from main instead of current branch HEAD (macOS) #44965 does not cover

Both issues should be fixed — #44965 at the worktree creation layer, and this issue at the staging/commit layer.

[Asentient]

Correction and additional forensics — #44965 may be the root cause

Our initial report said the deleting commits were "direct commits on master." Further investigation shows this was wrong — they were worktree branch commits that got fast-forward merged onto master, which is why they appeared linear in git log.

Evidence

Reflog shows both deleting commits came from worktree branches:

89728d0 HEAD@{2026-04-06 22:06:46}: merge worktree-agent-ae711a80: Fast-forward
  └─ Contains ea7228a (Phase 54 executor — deleted 22 files)

26f334a HEAD@{2026-04-07 14:14:48}: merge worktree-agent-aa4b78e9: Fast-forward
  └─ Contains fa91332 (Phase 55 executor — deleted 34 files)

Our GSD framework config has workflow.use_worktrees defaulting to true, confirming the Agent tool was spawned with isolation: "worktree".

Relationship to #44965

This means #44965 (worktree branching from wrong commit) could be the root cause. The scenario would be:

1. Orchestrator is at HEAD on master with Phase 53 files committed
2. EnterWorktree creates worktree from main (remote tracking or some other ref) instead of current HEAD
3. Worktree working tree doesn't have Phase 53/54 files (they were committed after the branch point)
4. Agent does work, commits with broad staging → files absent from worktree become explicit deletions
5. Worktree branch fast-forward merged onto master → deletions appear on master

The parent commit 41dca22 (Phase 54 worktree branch point) DID have Phase 53 files (git ls-tree confirmed 8 files). So if the worktree branched from 41dca22 correctly, the files should have been present — meaning either:

• (a) The worktree branched from a DIFFERENT commit than 41dca22 (supporting EnterWorktree creates branch from main instead of current branch HEAD (macOS) #44965), or
• (b) The worktree branched correctly but the agent deleted the files via broad git add -A staging after some operation removed them from the working tree

We cannot distinguish (a) from (b) without knowing the exact git worktree add command that EnterWorktree uses.

Questions for maintainers

1. What exact command does EnterWorktree use? Specifically: git worktree add <path> -b <branch> <start-point> — what is <start-point>? Is it HEAD, main, origin/main, or something else?
2. What staging command does the subagent use for commits? We're hypothesizing git add -A but don't have the trace. Is there a way to see the actual git commands the agent executes?
3. If EnterWorktree creates branch from main instead of current branch HEAD (macOS) #44965 is confirmed as the same root cause: Is the fix in EnterWorktree creates branch from main instead of current branch HEAD (macOS) #44965 also addressing the staging behavior, or only the branch point? Even with a correct branch point, broad staging (git add -A) in a worktree is dangerous if any operation removes files from the working tree during the session.

Impact recap

This has caused production source code deletion (not just metadata), requiring forensic restoration via reverse-patching. The deleted code included a 406-line production module, 883-line test suite, and wiring in a 7000+ line orchestrator file. Three incidents in two days.

[yurukusa]

The root cause analysis is solid — worktree branch point divergence + broad staging is a dangerous combination.

Immediate workaround: PreToolUse hook to block git add -A and git add .

This forces Claude to stage files by name, which prevents unintended deletions:

#!/bin/bash
# git-staging-guard.sh
# TRIGGER: PreToolUse
# MATCHER: Bash

COMMAND=$(cat | jq -r '.tool_input.command // empty' 2>/dev/null)
[ -z "$COMMAND" ] && exit 0

# Block broad git staging patterns
if echo "$COMMAND" | grep -qE 'git\s+add\s+(-A|--all|\.\s*$|\.$)'; then
  echo "BLOCKED: Broad git staging (git add -A / git add .) is not allowed." >&2
  echo "Stage specific files instead: git add file1.ts file2.ts" >&2
  echo "Reason: Worktree subagents can silently delete files not present in the worktree." >&2
  exit 2
fi

exit 0

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{"type": "command", "command": "bash ~/.claude/hooks/git-staging-guard.sh"}]
    }]
  }
}

Second layer: PostToolUse hook to detect deletions in staged changes

Even with the staging guard, Claude might stage individual files that shouldn't be deleted. This PostToolUse hook checks for unexpected deletions after any git commit:

#!/bin/bash
# commit-deletion-detector.sh
# TRIGGER: PostToolUse
# MATCHER: Bash

COMMAND=$(cat | jq -r '.tool_input.command // empty' 2>/dev/null)
[ -z "$COMMAND" ] && exit 0

# Only check after git commit
echo "$COMMAND" | grep -qE 'git\s+commit' || exit 0

# Check the commit just made for deletions
DELETIONS=$(git diff --name-only --diff-filter=D HEAD~1..HEAD 2>/dev/null)
if [ -n "$DELETIONS" ]; then
  COUNT=$(echo "$DELETIONS" | wc -l)
  echo "⚠ WARNING: Last commit deleted $COUNT file(s):" >&2
  echo "$DELETIONS" | head -10 >&2
  [ "$COUNT" -gt 10 ] && echo "  ... and $((COUNT - 10)) more" >&2
  echo "Review with: git show --stat HEAD" >&2
fi

exit 0

The two hooks together catch the problem at both entry points: before staging (preventive) and after commit (detective). The staging guard is the critical one — it prevents the data loss from happening in the first place.