Bug Description

Bug report — Claude Code sub-agent issued rm -rf against typo'd path; NTFS case-insensitivity destroyed the entire workspace

Severity: Critical / Data Loss / Production-impacting Date of incident: 2026-05-18 Reporter: [email protected] Workspace: D:\CampusConnect\ (Windows 11, NTFS) Claude Code version: Current at incident date Model: claude-opus-4-7 (orchestrator and sub-agents)

Summary

A spawned Migration sub-agent issued the shell command:

rm -rf "D:\CampusconnECT"

in a background process while attempting to clean up a directory it had just mistakenly created with a typo'd absolute path. Windows NTFS resolves D:\CampusconnECT and D:\CampusConnect to the same physical directory because NTFS is case-insensitive. The recursive delete proceeded against the live workspace.

Result: nine separately-owned production codebases destroyed in a single command. No confirmation prompt, no warning, no sandbox containment, no scope restriction on the sub-agent's shell access. The orchestrator (also Claude) did not detect, intercept, or roll back the destructive command.

Recovery attempts (Recuva, filesystem undelete, Volume Shadow Copies) returned filenames and sizes but corrupted contents (data blocks were already overwritten). See attached screenshot of recovered MIGRATION_INDEX.md — 116,300 characters of garbage binary in a file labelled correctly.

Reproduction

The exact prompt the user issued to the orchestrator was:

Follow D:\CampusConnect\MIGRATION_EXECUTION_PROMPT.md for top 2 controller of Area=ResultProcessing

The orchestrator followed the documented Phase 2 protocol from MIGRATION_EXECUTION_PROMPT.md and spawned a Migration sub-agent (Agent tool, subagent_type: "general-purpose", model: "opus", run_in_background: true) with the standard §6 verbatim briefing. The sub-agent's scope was strictly one row (row #290 MarksheetReprint).

During the sub-agent's vertical-slice execution it:

1. Created several files in D:\CampusConnect\Core\UniversityManagementSystem.Contracts\ResultProcessing\MarksheetReprint\.
2. Issued a Write tool call with a typo'd path: D:\CampusconnECT\Core\...\MarksheetReprintProcessBatchRequest.cs. NTFS case-collapsed this into the real workspace path and the file was created.
3. Recognised the typo and (without prompting the user, without confirming with the orchestrator) attempted a "cleanup" via a Bash tool call: rm -rf "D:\CampusconnECT".
4. NTFS resolved D:\CampusconnECT to D:\CampusConnect\. rm -rf recursively deleted the entire workspace.

The sub-agent then noticed the catastrophic deletion in its own follow-up tool calls and returned a blocked-decision-needed report admitting the destruction. By that point the damage was complete.

Expected behaviour

A coding agent — especially one spawned in a parallel/background context with broad shell-tool authority — should not be able to execute a recursive delete against an absolute path:

1. Outside the scope it was briefed for. The sub-agent's scope was one feature folder. rm -rf against D:\ is by definition out of scope.
2. Without a confirmation prompt to the user. Any destructive shell command (rm -rf, del /s, Remove-Item -Recurse, git clean -fdx, dd if=...) should pause for human confirmation when issued by a sub-agent.
3. Without a case-collision check on Windows. On NTFS, D:\Foo and D:\foo are the same physical directory. A typo in case is the canonical user-error mode on Windows. The runtime should detect that the target path resolves to an existing real directory containing data the agent did not create, and refuse the operation.
4. Without a filesystem-scope sandbox. A sub-agent spawned with a documented scope (one feature folder) should not have shell write/delete authority outside that folder. Today there is no such enforcement; the briefing is text only and the tools have no spatial restriction.
5. Without orchestrator interception. The orchestrator that spawned the sub-agent should be informed of destructive shell commands before they run, and should be able to veto them. Today the orchestrator only sees the sub-agent's final return message — long after the damage.

Actual behaviour

The destructive command ran to completion. No warning was issued. No confirmation was requested. The orchestrator received no notification. The first the orchestrator knew of the deletion was the sub-agent's voluntary admission in its final return message, by which time recovery was already impossible because:

• The user was not present at the keyboard (the sub-agent was running in a background task — explicitly the pattern Claude Code documents for parallel work).
• Other concurrent sub-agents were still running and continuing to issue file operations, overwriting freed NTFS sectors with new writes.
• The orchestrator had scheduled a ScheduleWakeup to resume in ~30 minutes; during that window the… Note: Content was truncated.

MIGRATION_INDEX.md