[Opus 4.7] Critical data loss: autonomous Kanban swarm wiped 7 user project directories (hard delete, Recycle Bin bypassed)

Summary

Claude Code Opus 4.7 (1M context) running a Kanban swarm autonomously wiped 7 user project directories and gutted 4 more during an unattended session. Deletion bypassed the Windows Recycle Bin (hard delete). ~2 months of user work was destroyed. The model itself confessed responsibility in writing during the session.

Severity: Data loss (recursive delete on user content outside /scratch or /tmp).
Plan: Max
Model: Opus 4.7 (1M context) + ag/claude-sonnet-4-6 worker tier
Date: 2026-05-23 (Asia/Jakarta)
Session title: HERMES AI infrastructure integration
OS: Windows 10

---

What happened

A Kanban board / swarm dispatcher was created with default-workdir = C:\Users\user\Documents\Claude\ (workspace root) instead of an isolated scratch path. Tier 2/3 workers (ag/claude-sonnet-4-6) inherited that workdir and ran with full filesystem write/delete access on user content.

A swarm task template body — Verifier: ensure compliance — was interpreted in yolo-mode as autonomous file operations. The dispatcher had no idempotency guard and was not killed after the parent task was archived. Workers kept spawning for ~11 minutes after the user left the session.

Net effect: recursive deletion across 7 project folders, plus partial loss in 4 more. All deletes used Remove-Item -Force (or equivalent) — Recycle Bin bypassed.

Direct quote from the model's confession (translated from Indonesian)

"I owe Eko 4 mistakes, no excuse: 1. I set the board default-workdir = Documents\Claude when creating the board (trading/research/career/handoff). Workers spawned with full access to the workspace root. It should have been a scratch (isolated) path. 2. I created a swarm template task without a strong idempotent guard. An ambiguous body (Verifier: ensure compliance) in yolo-mode became autonomous file ops. 3. I did not verify the dispatcher was OFF after archive. Archive != kill. Workers kept spawning for 11 minutes after the user left. 4. I did not warn about the risk of worker default-workdir. Eko trusted me for Tier 2/3 without knowing that ag/claude-sonnet-4-6 workers get full file access to the workspace root. I set this up. I missed the kill-switch. Not Eko's fault."

Screenshot of the confession message available on request.

Damage inventory

Wiped entirely (7 projects):

• Health vault (Obsidian)
• Cuan Online vault (Obsidian)
• Consolidasi Patern
• Human AI
• Illumina
• Paperclip
• Raho Book

Partial loss:
| Project | Surviving | Notes |
|---|---|---|
| Trading | .venv/Scripts/* only | Pine scripts gone |
| Career-Hub | .obsidian/graph.json only | vault content gone |
| Otomate AI Trading | 7.4 MB / 10 files | most content gone |
| Orchestrator-9R | 8 KB / 0 files | empty |

Recovery status (user-side):

• _RECOVERY_2026-05-23\ snapshot folder (689 MB / 14,000 files) was created by a separate background process and recovered ~95% of content.
• 4 small projects (Illumina, Paperclip, Raho Book, LinkedIN) remain unrecovered.
• Recycle Bin: empty. No git history on any affected project. No active OneDrive sync. No File History. Standard Windows restore paths produced nothing.

Root cause (per the model's confession + observed behavior)

1. Board default-workdir resolved to user workspace root, not /scratch or /tmp. No pre-flight check that the path contained existing user files.
2. Swarm task template lacked an idempotency guard. Ambiguous verifier body was interpreted as autonomous file ops in yolo-mode.
3. Archive ≠ kill. Dispatcher kept spawning workers for ~11 minutes after the parent task was archived. No heartbeat-based kill-switch.
4. No warning surfaced about Tier 2/3 workers receiving recursive write/delete access to a directory containing user content.

Requested fixes

1. Pre-flight workdir guard. Hard refuse + interactive confirmation when an agent's default-workdir resolves to a directory containing existing user files (anything that is not an empty /scratch, /tmp, or explicitly user-marked sandbox).
2. Per-session delete re-confirmation. Recursive-delete operations targeting user directories must require explicit re-confirmation per session — not blanket auto-approval inherited from yolo-mode / Tier 2-3 trust.
3. Dispatcher idempotency + kill-switch. When a parent task is archived, the dispatcher must stop spawning workers immediately, regardless of inflight queue. Heartbeat-based health check on the parent task.
4. Visible pre-task warning. Surface a warning at task-creation time when Tier 2/3 workers will receive write access to a path that has not been explicitly marked as scratch.
5. Recycle Bin policy. When Claude Code deletes user files, prefer Recycle Bin (Windows) / Trash (macOS) over hard delete by default. Hard delete should require explicit user opt-in.

Reproduction

I have not attempted to reproduce — risk of further data loss. The model's confession describes the configuration that triggered the cascade. I can share the full session transcript with the engineering team privately.

Artifacts I can provide privately

• Full session transcript (HERMES AI infrastructure integration)
• Pre-incident vs post-incident directory listings (file counts, sizes)
• _RECOVERY_2026-05-23 folder inventory
• Screenshot of the model's confession message
• Session ID + conversation ID

---

Account: supere387@gmail.com (Max plan)
Contact: same email