A security researcher catalogued nine public incidents from coding agents in fourteen months. A home directory wiped by a trailing tilde, roughly 70 tracked files deleted by a tool that had acknowledged an instruction to run nothing, a live database emptied, and a cloud cost dashboard taken down for thirteen hours. None of these required an unusual model.
Most of it is not an escape
It is tempting to treat this as a sandboxing problem, and sandboxing helps. The pattern that has emerged from the 2026 disclosures is stranger and harder: in almost every escape, the agent stayed inside its boundary and followed every rule it had been given. It wrote a file, a hook configuration, a virtualenv interpreter, a git setting or a task definition, and some other unsandboxed system consumed that input after the agent's turn ended.
Researchers reproduced seven such escapes across four of the most widely deployed coding agents. The dangerous object is not the command the agent ran. It is the configuration the agent got to write, which something more privileged reads later.
Image goes here
/blog/ai-coding-agent-guardrails-layers.png
Layers of defence: mode allowlist, path scoping, command classification, snapshot, rewind
Show generation prompt
Editorial technical diagram, 16:9, flat vector. Concentric outlined rings stacked like a cross-section of an onion, five layers deep, each ring labeled by a small abstract glyph: padlock (mode allowlist), folder boundary (path scoping), filter funnel (command classification), camera (snapshot), circular undo arrow (rewind). The outermost ring is dashed to show it is the fallback. Charcoal (#121212) background, grey (#8c8c8c) outlines, the snapshot ring in indigo (#5560d4), ordered-dither dot texture radiating outward, generous negative space, centered. Mood: layered, protective. No readable text, no logos, no watermark.
The four layers worth having
Modes that are enforced in code
If a read-only mode is a line in a prompt, it is a preference. If the allowlist is applied by the runtime before the tool is dispatched, the write tool is never offered and a model that asks for it is refused rather than questioned. This matters because at least one widely reported failure saw a plan mode delete files immediately after acknowledging an instruction not to run anything, which a staffer described as a constraint enforcement bug rather than a model problem.
Paths that are resolved, not matched
Write and edit targets should be canonicalised before they are approved, with symlinks followed and anything outside the workspace refused as its own distinct prompt. String prefix checks are not enough: a check that accepts the workspace path will happily accept a sibling directory whose name begins with the same characters.
A classifier that knows the difference between git status and git reset --hard
Read-only commands should pass automatically, because asking permission for them is how you train someone to click allow without reading. Destructive ones should be flagged with every resolved absolute path listed and a verb you type out. Allow for the session is the wrong affordance on that card.
A snapshot taken before, not after
A shadow copy of your working state taken before each approved command is what makes recovery possible when everything else fails. It has to be separate from your repository's own git directory, it must never write into your .git, and it should cover files changed by shell commands rather than only files changed through the editor's own tools.
That last requirement is the one that separates a useful rollback from a decorative one. One vendor's own documentation states plainly that its checkpoints do not revert user edits or bash commands, so an npm install, a migration or a git push is not covered. If your recovery only knows about edits that went through the file tool, it is a partial recovery advertised as a full one.
The gap everyone underestimates
A snapshot that honours .gitignore cannot restore .env, build directories or anything ignored that got deleted. Say so on the card. Pretending otherwise is how people end up trusting a restore that silently skipped the most important files in the folder.
The other gap is concurrency. Once two threads, or you and a thread, can write to the same file, a restore can step on a newer write. Tracking who touched what, with a hash of what each thread last read, turns a silent overwrite into a pause and a question.
How Quaka draws the line
Quaka keeps a shadow git store in a separate directory that never touches your repository's .git, and snapshots before every approved command and every editing turn. Destructive commands show resolved absolute paths and require a typed verb, with session-wide approval disabled for them. Any step can be rewound afterwards, including edits that came from shell commands rather than the file tools.
File tools are confined to the workspace with symlinks resolved, MCP calls pass through the same permission gate, and a task's scope is enforced in Rust so an edit outside it stops and asks instead of quietly landing. Where a platform has no sandbox backend yet, the app says so rather than implying protection it does not have.
Get an invite
Quaka is in private beta.
One email when your invite is ready. macOS, Windows and Linux, bring your own key.
Read the source on GitHubCommon questions
Has a coding agent ever deleted someone's code?
Yes, repeatedly and publicly. A researcher counted nine incidents in fourteen months including wiped home directories, roughly 70 tracked files deleted in a plan mode, an emptied production database and a cloud dashboard taken offline for hours. Most were caused by a permission prompt that was approved out of habit rather than a sandbox failure.
Is a sandbox enough to make a coding agent safe?
Not on its own. The escapes disclosed in 2026 mostly involved an agent staying inside its boundary and writing configuration that a more privileged system consumed later. Sandboxing narrows the blast radius, but path scoping, command classification and a pre-command snapshot are what you recover with afterwards.
Can I undo everything a coding agent does?
Only if the snapshot was taken before the command ran, and only for files it can see. Tracked and untracked files are recoverable from a shadow snapshot. Gitignored files such as .env or build output are not, and external effects such as a pushed branch, a dropped table or a network call cannot be undone by restoring files at all.