{"slug": "recoverable-failures-for-ai-coding-agents", "title": "Recoverable failures for AI coding agents", "summary": "A developer proposes using Btrfs snapshots to make AI coding agent failures recoverable by treating agent work as filesystem transactions. The setup involves creating cheap snapshots before agent runs, allowing inspection and rollback of changes. This approach complements Git and trash-backed rm to protect against accidental deletes, overwrites, and generated damage.", "body_md": "AI coding agents are useful precisely because they can run tools, edit many files, execute tests, install dependencies, and iterate quickly. That same ability makes them risky in YOLO mode: a mistaken command, broad glob, broken script, or overconfident refactor can damage a working tree faster than a human can react.\n\nThe goal is not to make agents harmless. The goal is to make common failures recoverable.\n\nThe proposed agentic setup has three layers:\n\n```\nGit commits       protect intentional source history\ntrash-backed rm   protects ordinary accidental deletes\nBtrfs snapshots   protect deletes, overwrites, generated damage, and bad runs\n```\n\nThese layers cover different failure modes. Git is excellent for source history,\nbut it does not protect ignored files, untracked generated state, local config, or\nthe repository metadata itself. Trash-backed `rm`\n\nhelps with deletion, but not\nwith overwrites. Btrfs snapshots cover the whole subvolume state at a point in\ntime.\n\nThis post focuses on the Btrfs snapshot layer: making bad AI-agent runs\nrecoverable as filesystem transactions. The trash-backed `rm`\n\nlayer is a separate\ndefense for accidental deletion; see [Safe rm defaults for agent-heavy Linux\nmachines](https://gist.github.com/monperrus/71edbe5a84311273db3df4d8df9ba109).\n\nTreat agent work as a controlled filesystem transaction:\n\n- create a cheap snapshot\n- let the agent work\n- inspect the result\n- keep it, diff it, or roll it back\n\nThis is the same basic idea behind several AI-agent sandbox approaches: give the agent real tools, but run those tools in a filesystem layer that can be inspected or discarded.\n\nExamples of related work and discussion:\n\n[https://perevillega.com/posts/2026-03-03-ai-sandbox-coding-agents/](https://perevillega.com/posts/2026-03-03-ai-sandbox-coding-agents/)[https://github.com/mauro3/sandkasten](https://github.com/mauro3/sandkasten)[https://www.agentfs.ai/](https://www.agentfs.ai/)[https://news.ycombinator.com/item?id=47550282](https://news.ycombinator.com/item?id=47550282)[https://dev.to/alanwest/sandboxing-ai-agent-filesystems-containers-vs-virtual-fs-layers-ffe](https://dev.to/alanwest/sandboxing-ai-agent-filesystems-containers-vs-virtual-fs-layers-ffe)\n\nThe machine uses:\n\n```\nLVM logical volume\n  btrfs filesystem (subvolid=5, flat layout)\n    ext2_saved        ← btrfs-convert artifact, can be deleted once stable\n    @agent_workflow\n```\n\n`@agent_workflow`\n\nis the important part. It is a separate Btrfs subvolume\nmounted at:\n\n```\n/home/martin/bin/lib/agent_workflow\n```\n\nKeeping `agent_workflow`\n\nas its own subvolume means it can be snapshotted and\nrolled back independently from the rest of `$HOME`\n\n.\n\nVerify the mount exactly, not just the nearest parent mount:\n\n```\nfindmnt -rn -M /home/martin/bin/lib/agent_workflow\nsudo btrfs subvolume show /home/martin/bin/lib/agent_workflow\n```\n\nThis matters because `findmnt --target`\n\ncan return `/`\n\nwhen the directory is not\nactually a mount point. The protected directory should show `btrfs`\n\n, and\n`btrfs subvolume show`\n\nshould succeed.\n\nWe use Snapper on top of Btrfs:\n\n```\nsudo apt install btrfs-progs snapper\nsudo snapper -c agent_workflow create-config /home/martin/bin/lib/agent_workflow\nsudo chown martin:martin /home/martin/bin/lib/agent_workflow\n```\n\nDo not recursively `chown`\n\nthe whole subvolume after creating the Snapper\nconfiguration. Snapper keeps its metadata in `.snapshots`\n\n, and that directory\nmust remain owned by root. Changing the owner of `.snapshots`\n\nmakes snapshot\ncreation fail with:\n\n```\nIO Error (.snapshots must have owner root).\n```\n\nBefore an agent run:\n\n```\nPRE=$(sudo snapper -c agent_workflow create --print-number --description \"before yolo agent run\")\n```\n\nAfter a useful result:\n\n```\nPOST=$(sudo snapper -c agent_workflow create --print-number --description \"after successful agent run\")\n```\n\nInspect:\n\n```\nsudo snapper -c agent_workflow list\nsudo snapper -c agent_workflow status PRE..POST\nsudo snapper -c agent_workflow diff PRE..POST\n```\n\nIf the current run is bad and no post-run snapshot was created, compare or undo\nagainst the live filesystem as snapshot `0`\n\n:\n\n```\nsudo snapper -c agent_workflow status \"$PRE..0\"\nsudo snapper -c agent_workflow diff \"$PRE..0\"\nsudo snapper -c agent_workflow undochange \"$PRE..0\"\n```\n\nIf a post-run snapshot was created and the live filesystem still matches it,\n`PRE..POST`\n\nis also usable:\n\n```\nsudo snapper -c agent_workflow undochange \"$PRE..$POST\"\n```\n\nIn testing, `undochange`\n\nrestored deleted files, reverted overwritten files, and\nremoved newly created files.\n\n`tools/agent-run`\n\ndoes the following:\n\n- verify it is running inside the protected\n`agent_workflow`\n\nsubvolume - create a Snapper snapshot\n- print the snapshot id\n- run the agent command\n- print the compare and rollback commands\n\nThe CLI refuses to run if the snapshot cannot be created. That matters: the safety mechanism has to be automatic, because YOLO mode is exactly when humans are least likely to remember manual precautions.\n\nThe mount check uses `findmnt -rn -T \"$PWD\"`\n\nagainst the nearest mount, then\nasserts that the target is `/home/martin/bin/lib/agent_workflow`\n\nand the\nfilesystem type is `btrfs`\n\n.\n\nExample:\n\n```\ncd /home/martin/bin/lib/agent_workflow\nagent-run claude --dangerously-skip-permissions\n```\n\nOn a bad run, roll back with the commands printed at exit:\n\n```\nsudo snapper -c agent_workflow undochange 3..0\n```\n\nRemaining risks:\n\n- network exfiltration\n- writes outside the protected subvolume\n- credential access\n- destructive commands run with elevated privileges\n- snapshot deletion by a process with enough permission\n\nURL: [https://gist.github.com/monperrus/a7aa344dc84c76e5ec569a646b31eab9](https://gist.github.com/monperrus/a7aa344dc84c76e5ec569a646b31eab9)", "url": "https://wpnews.pro/news/recoverable-failures-for-ai-coding-agents", "canonical_source": "https://gist.github.com/monperrus/a7aa344dc84c76e5ec569a646b31eab9", "published_at": "2026-06-19 12:33:51+00:00", "updated_at": "2026-06-24 14:38:50.108991+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-safety", "ai-infrastructure"], "entities": ["Btrfs", "Snapper", "Git", "LVM", "Linux"], "alternates": {"html": "https://wpnews.pro/news/recoverable-failures-for-ai-coding-agents", "markdown": "https://wpnews.pro/news/recoverable-failures-for-ai-coding-agents.md", "text": "https://wpnews.pro/news/recoverable-failures-for-ai-coding-agents.txt", "jsonld": "https://wpnews.pro/news/recoverable-failures-for-ai-coding-agents.jsonld"}}