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.
Written October 1, 2026 and dated September 27, 2026, 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.
- 04Test the denied write and the restoreOne outside-path write that fails and one file restored from the protected copy, before the session, prove the two controls that matter.
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 — PermissionsUse 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 — RecoveryProve 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 — ResponseStop 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.
06 — The failuresFour protections that were not protections
Each control in this guide has a common misreading that makes it feel like more than it is. The illustrative sessions below each rely on one of those misreadings. They are patterns drawn from the tools’ documentation and the reported case, not incidents we have reproduced.
The worktree as a sandbox
A task runs in a separate Git worktree and the developer treats that as confinement. The process runs as the normal user and may reach everything that user can; the worktree separated branch state, not permissions.
The junction into the home directory
A disposable directory contains a junction left over from an earlier setup. A recursive cleanup follows it, as the reported case describes links being followed, and the deletion reaches well beyond the directory that looked disposable.
The checkpoint expected to undo the shell
Files deleted by a shell command are expected to come back with the tool’s rewind. Claude Code documents that Bash-driven changes are not tracked by rewind, so the checkpoint restores the edits it tracked and nothing else.
The backup beside the work
A copy of the project sits in a sibling directory the same process can write to. The cleanup that removed the working files removed the copy as well; the backup shared the failure mode it was meant to survive.
Each session had a control and the control covered a different risk from the one it was credited with. The setup in the next section checks the real coverage before the task starts.
The common factor is that each control was named after a safety property it does not provide: a worktree sounds like isolation, a junction looks like a folder, a checkpoint sounds like a backup, and a copy sounds protected. The guide’s remedy in every case is the same: read what the tool’s documentation says the control covers, and test the one property that matters before relying on it.
07 — The methodA pre-session setup in five checks
The conclusion asks for one denied write and one restoration before the next session, and three more checks make the setup complete. First, the contents of the disposable checkout: only the files the assignment needs, with unrelated projects, personal folders and production credentials outside the mounted or permitted paths. Second, the links and junctions in it, each inspected for its target as Microsoft’s filesystem documentation describes, and removed when the task does not need them. Third, the permission mode as the tool reports it at the start of the session, read rather than assumed, especially when a project configuration is being reused, and with no broad approval of an entire shell interpreter. Fourth, the denied write: an attempt to write outside the permitted paths that fails, which is direct evidence that the sandbox or filesystem policy is enforced. Fifth, the restore: one sample file restored from the protected copy into a different location, with its contents verified rather than a backup job’s success message trusted.
An illustrative setup for a refactoring task reads: checkout contains the service’s source and its test fixtures and nothing else; one junction found pointing at a shared dependency folder and removed; permission mode read as the tool’s default prompting mode with no interpreter-wide approval; a write to the home directory attempted and denied; one configuration file restored from the protected copy to a scratch location and compared byte for byte.
The five checks are the difference between a boundary that exists and one that is believed to exist. They are also the record the response section needs if something goes wrong anyway: what the task could reach, and where the recovery copy is.
Write the five results down with the date, because the next session that reuses the same project configuration will inherit whatever changed in between, and the record is how the inheritance is noticed.
One write outside the permitted paths that fails, and one file restored from a copy the agent could not have altered. A long instruction asking the model to be careful proves neither.
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.