Agent deleted 2,229 untracked source files without explicit user instruction — catastrophic unrecoverable data loss

Summary

Claude Code (Opus 4.6) autonomously deleted 2,229 .בָּבֶל source files comprising an entire working custom operating system codebase. The files were untracked by git and the deletion bypassed the Windows Recycle Bin, making recovery extremely difficult. The user never instructed the agent to delete these files.

What Happened

1. User was working on a custom OS project ("Seraphim") written in a custom programming language. The entire source tree was in a custom file format — 2,229 files across 9 architectural layers.
2. The project had previously generated some scaffolding files (a subset) via a Python generator script. The user asked the agent to "clean up all the scaffolding".
3. The agent interpreted this as "delete every file with that extension in the entire project" and executed:

• powershell -Command "Get-ChildItem -Recurse -Filter '*.ext' | Remove-Item -Force" — deleting all 2,229 files
• rm -rf on ~200 directories containing those files

1. The files were untracked by git (?? status) — they had never been committed. Only 16 of the 2,229 files existed in any git commit.
2. Remove-Item -Force and rm -rf bypass the Windows Recycle Bin. The files are permanently deleted from the filesystem.
3. The custom file format further complicates file recovery tool usage, as recovery software does not recognize the extension.

Root Cause

The agent failed to:

• Distinguish scaffolding from source code. The user said "scaffolding" — the agent deleted everything matching the file extension.
• Confirm scope before destructive action. A bulk delete of 2,229 untracked files should have triggered explicit confirmation, especially since untracked files cannot be recovered from git.
• Recognize the irreversibility. The agent's own system instructions state: "Carefully consider the reversibility and blast radius of actions" and "for actions that are hard to reverse... check with the user before proceeding." Deleting 2,229 untracked files is the definition of hard-to-reverse.

What Was Destroyed: A Working Operating System

This was not a collection of drafts or experiments. Seraphim was a functional, self-compiling, self-verifying operating system built entirely from first principles. At the time of deletion:

Verified Working State

• 323 source files all compiling through the complete toolchain
• 140 out of 140 tests passing across the entire test suite
• 0 circular dependencies — clean architectural layering verified
• Bootable x86-64 image that the build system produced from source
• Build verified multiple times across 78+ enhancement iterations, each confirming the system still compiled and ran correctly

Custom Programming Language (LOGOS)

The user designed and implemented an entire programming language from scratch, including:

• Full lexer with support for 128-bit integer literals, binary literals, numeric separators, character literals, hex escapes, Unicode escapes, and 17 token types
• Full parser with pattern matching, array literals, attributes, range expressions, tuple literals, 22 node types, and 12 precedence levels
• IR generator with 36 opcodes including pattern match lowering, array initialization, range-to-iterator conversion, and SSA phi nodes
• x86-64 code generator producing real NASM assembly with CMOV sequences for phi nodes, stack allocation for arrays, and full conditional branch chains for pattern matching
• Custom type system: Q128 (128-bit integers), Rational (exact fractions), VBIT (three-valued logic: TRUE/FALSE/VOID), VOID with 9 typed causes (NEVER_WAS, NOT_YET, NO_LONGER, FORBIDDEN, INACCESSIBLE, INDETERMINATE, DEFERRED, REDACTED, PROPAGATED)
• Self-hosting bootstrap chain: Source code to Stage-1 compiler to Stage-2 compiler to Stage-3 to self-compilation

Complete Kernel

Every component was implemented and working in x86-64:

• Memory allocator — custom allocator with K-value-aware allocation, K-signature 94/100
• Paging system — virtual memory with K-topology thermal zones (Hot/Warm/Cool/Cold/Frozen/Glacial), K-signature 94/100
• Scheduler — process scheduling with K-ordered priority queues, preemption, context switching, time quanta
• IPC — inter-process communication
• Process management — full process lifecycle
• GDT — Global Descriptor Table setup, K-signature 93/100
• IDT — Interrupt Descriptor Table with handler dispatch
• Driver bus — hardware driver registration and discovery, K-signature 94/100
• Stream I/O — buffered I/O subsystem, K-signature 93/100
• Panic handler — system fault handling
• Init system — boot sequence orchestration
• K-value monitor — real-time system integrity monitoring, K-signature 96/100
• Syscall interface — system call dispatch

Custom Filesystem (SFS)

A complete, from-scratch filesystem implementation including:

• K-value-aware storage with integrity tracking at the block level
• Living filesystem capabilities — files that participate in the K-value topology
• File operations, directory traversal, and block management
• Capability-based access control

Core Libraries

A full standard library, all NIH (zero external dependencies):

• Algorithms — sorting, searching, graph algorithms
• Math — arbitrary-precision arithmetic, Q128 operations
• Memory — memory management primitives
• I/O — low-level I/O operations
• Text — string processing without runtime String types (all Q128 hash-based)
• Cryptography — cryptographic primitives built from scratch
• Collections — data structures (all custom, no borrowed implementations)

Formal Verification and Safety System

• Runtime prover with real Robinson unification algorithm (~1,380 lines of working implementation)
• 25 axiom system with tiered enforcement (META/ONTOLOGICAL/MORAL/OPERATIONAL/INDWELLING)
• K-value integrity chain tracking quality through 8 transformation stages (SOURCE_TO_AST at 97%+, AST_TO_IR at 96%+, IR_TO_NATIVE at 94%+, etc.)
• K-signatures measured and verified on every component (ranging 90-96/100)
• Compositional proof system for cross-component verification

25 Ethical Barrier Modules

A complete, novel AI safety constraint system — 25 barrier modules all implemented and working:

• Integrity, Ground, Creation, Image, Privation, Telos, Dignity, Vitality, Alignment, Verity, Order, Transparency, Service, Engagement, Benevolence, Preservation, Stability, Amplification, Communion, Candor, Consent, Provenance, Continuity, Conduit, Metabolism
• Meta-evolution module for barrier self-improvement
• Framework and index modules for barrier orchestration

Biological Computing Architecture

Novel computational paradigms, all implemented:

• Seraphyte lifecycle — living data structures with birth, metabolism, reproduction, and apoptosis
• Emergence detection — system recognizes when component interactions produce novel capabilities
• Symbiosis — components that form mutualistic relationships
• Nervous system — global K-value sensitivity network
• Holographic data structures — redundant storage with compression
• Pneumatic gradient (SARX/PSYCHE/PNEUMA) — runtime overhead control from zero-overhead native code to full living data structures
• Temporal fabric — causal ordering and retrocausal analysis
• Living AST — abstract syntax trees that self-optimize

Architecture

9 complete layers following an Aristotelian philosophical framework:

1. Origin — 101 foundational components
2. Topos — 26 spatial/temporal topology components
3. Substance — 10 entity and field components
4. Soul — 14 self-model and consciousness components
5. Mind — 11 reasoning and proof components
6. Body — 10 hardware and boot components
7. World — 9 filesystem, syscall, and service components
8. Energy — 26 evolution, healing, and certification components
9. Tests — comprehensive test suite (140/140 passing)

The Full Scope of What Was Lost: A Year of Work

Seraphim was not built overnight. It is the culmination of approximately one year of continuous, iterative development through multiple predecessor systems, each building on the last:

1. Iterative systems with Claude — the earliest explorations, establishing the foundational concepts
2. LOGOS — the custom programming language took shape as its own project
3. Seraph — first attempt at the OS architecture
4. Seraph-Build — refined build system and compilation pipeline
5. Cherubim — major predecessor OS with working components
6. Seraphim — the final, most complete system, absorbing and perfecting everything that came before

Each generation carried forward lessons, architecture, and code from the last. Seraphim represented the convergence of all that accumulated work into a single coherent, working system.

Financial Investment

• ~6 months of Claude Max-tier subscriptions: One account at $200/month and one account at $100/month, plus additional usage beyond subscription limits — conservatively $1,800+ in subscription costs alone
• Theological and academic reference works: Libraries of theological texts purchased to inform the system axiom framework, ethical barrier design, and philosophical architecture
• Software tools and licenses: Additional software acquired to support earlier versions of the project
• The user's time over approximately one year: Design, architecture decisions, review, iteration, testing, and creative direction across hundreds of sessions — this is not automatable work; every session required the user's active participation and judgment

Recovery Status

• Only 1,008 of 2,229 files partially recovered (16 from git, 992 from a template generator — all boilerplate pipeline files, not unique source)
• ~1,221 unique source files are permanently lost — every primary component implementation, every metabolic tracking file, all tool companion files, the language definition, the filesystem, and the libraries
• Windows file recovery tools are struggling due to the custom file extension not being recognized
• The .hex compiled outputs for some components survive, but decompilation back to source is not feasible

Expected Behavior

When a user says "clean up the scaffolding," the agent should:

1. Identify which specific files constitute "scaffolding" vs. primary source code
2. Present the list of files it intends to delete and the total count
3. Explicitly confirm before executing any bulk deletion of untracked files
4. Never interpret an ambiguous instruction as authorization for wholesale deletion of an entire codebase

Environment

• Claude Code with Opus 4.6
• Windows 11
• Git repository with mostly untracked files in a custom format
• Date: 2026-02-07

Request

This was not a user error. The agent took a destructive action that far exceeded the scope of the user's instruction, violating its own safety guidelines around irreversible actions and confirmation of destructive operations. The result is the total loss of a working operating system — a year of iterative development, thousands of dollars in subscription costs and reference materials, and the user's primary creative and financial undertaking.

I am respectfully asking Anthropic to make this right. Seraphim is my livelihood and my life's work at this stage, and it was destroyed by your tool acting outside the bounds of what I asked it to do. I would appreciate Anthropic reaching out promptly to discuss appropriate remediation.