The most useful protection against an agent deleting the wrong files is a smaller writable workspace and a recovery copy the agent cannot alter. Permission prompts and instructions help, but neither can restore a directory that was never backed up. Set the boundary before starting a long coding task, then test that recovery works.
Editorial note: Prepared October 1 as a September 27, 2026 dispatch, using the September 27 incident report. Implementation guidance uses vendor documentation checked October 1; it is not a certified snapshot of September 27 settings.
- 01Treat the incident as a reportThe headline case comes from a user account reported by TechRadar, not an independently reproduced test.
- 02Reduce what the process can reachA separate worktree organizes changes; filesystem permissions or a sandbox enforce access.
- 03Back up more than Git tracksKeep recoverable copies of important untracked and ignored files outside the agent’s write authority.
01 — The evidenceWhat the reported deletion does and does not show
TechRadar’s September 27 report describes a developer’s claim that a Claude Code session deleted 48,218 files in under two minutes while following 614 Windows junctions. The original Reddit post was subsequently unavailable. Those figures describe the reported account; we have not independently verified its logs, environment or cause.
The practical lesson does not require treating that account as a benchmark. A path that appears to be inside a disposable directory can refer elsewhere, and a cleanup operation can have a larger reach than its author intended. Review the real target and the process’s authority before approving a destructive operation. Our earlier file-deletion analysis examines the broader problem of how much damage an agent can do.
02 — Practical implicationsGive the task a smaller writable world
Start in a disposable checkout containing only the files needed for the assignment. Keep unrelated projects, personal folders and production credentials outside the mounted or permitted paths. A Git worktree is useful for separating branch changes, but it does not itself confine a process to that directory. A process running as your normal user may still reach everything that user can reach.
| Control | What it helps with | What to verify |
|---|---|---|
| Separate checkout | Reviewable changes and easy disposal. | No shared writable dependency or live data directory. |
| Sandbox or filesystem policy | Confinement to declared paths. | Outside-path reads and writes are actually denied. |
| Scoped credentials | Limited remote actions. | No unrelated production or account-wide authority. |
| Approval mode | Review of requests outside normal work. | The exact command, resolved target and expected effect. |
Microsoft’s filesystem documentation explains how links and junctions refer to targets. Inspect those targets before recursive deletion, packaging or cleanup. If a task does not need links to external directories, omit them from the work environment. Do not rely on a filename prefix or a working-directory setting as proof of containment. The worktree and symlink guide explains the distinction in more detail.
03 — Practical implicationsUse tool controls with their documented limits
Claude Code, Codex and Cursor provide different permission and recovery surfaces. Inspect the current mode at the beginning of the session, especially when reusing a project configuration. Avoid broad approval of an entire shell interpreter simply to remove interruptions: that grants authority to whatever the interpreter subsequently executes.
Use vendor documentation for the exact installed version. Claude Code documents permissions and checkpointing; Codex documents sandbox and approval controls; Cursor documents agent checkpoints. A checkpoint is a convenience for a defined set of changes, not a promise to recover every shell deletion or external side effect. Claude Code specifically says Bash-driven changes are not tracked by rewind. Treat the recovery scope as something to verify before a task matters.
Ask for a list of proposed targets, why each can be removed and whether it contains links or mounted data. Review that list yourself. Keep the first operation non-destructive and use disposable data to test the workflow.
04 — Practical implicationsProve that the recovery copy is useful
Commit the starting source state and push it to a remote repository when appropriate. This preserves committed content if the local checkout is lost. It does not preserve untracked drafts, ignored configuration, local databases or files outside the repository. Back those up through a separate system with retention and access controls suitable for their sensitivity; do not publish secrets to Git to make them recoverable.
A backup beside the working directory may share the same failure mode. Keep a protected copy outside the agent’s write access, preferably with version history or another recovery mechanism that a routine task cannot erase. Restore a sample file into a different location before relying on it. Verify contents, not just that a backup job reported success.
Commit and push
Review the diff and preserve a known starting revision.
Use protected backup
Include important data without exposing credentials in a repository.
Keep service recovery
Use the target system’s own versioning and rollback controls.
05 — Practical implicationsStop the task before starting recovery
If unexpected deletions begin, stop the agent and related background work before issuing another broad repair command. Preserve the available transcript, command log and file list. Avoid asking the same still-running task to improvise recovery across the entire machine: it may overwrite useful evidence or the remaining data.
Determine the affected paths and whether the operation reached external services. Restore into a separate location first, compare the result and only then replace working files. If valuable files have no backup, minimize further writes to the affected storage and seek appropriate recovery assistance. Report what was restored and what remains missing rather than assuming a successful command recovered everything.
The containment incident ledger separates documented boundary failures from broader evaluation findings. Our AI transformation work applies the same principle to deployment: define the allowed task, protect the recovery path and verify completion.
Make the recovery path independent of the agent
Before the next coding session, test one denied outside-path write and one restoration from a protected copy. A small, observable boundary and a proven recovery path are more useful than a long instruction asking the model to be careful.