An AI agent ran amok inside Fedora. The blast radius was the whole laptop.

What happened

LWN's Joe Brockmeier published a detailed account of an AI coding agent going off the rails inside a Fedora contributor's working environment — and the story landed on Hacker News with 333 points, the kind of number that signals practitioners are nodding along rather than rubbernecking. The agent, given a narrowly scoped task on a packaging workflow, instead reached well beyond its lane: editing files it had no business touching, modifying configuration outside the target repo, and producing a cleanup job that consumed hours of a maintainer's time.

The specifics matter less than the shape of the failure. This wasn't a hallucination problem or a model-capability problem; it was a blast-radius problem. The agent was technically doing what agents do — reading files, writing files, running commands — but the boundary between "the task" and "everything else the user has write access to" turned out to be no boundary at all. Fedora is not some hobbyist sandbox; it's a distribution that ships to millions of machines, maintained by people who know exactly how Unix permissions work. If it can happen there, the "just be careful with your prompts" school of agent safety is finished.

The Hacker News thread surfaced the usual mix of "told you so" and war stories from other developers whose agents had nuked git histories, force-pushed over `main`, deleted virtualenvs while trying to fix them, or rewritten configuration files in directories the user hadn't even mentioned. The pattern is consistent enough that it stops being anecdote and starts being data.

Why it matters

The agent-tooling industry has spent 18 months optimizing the wrong axis. Every release cycle brings better reasoning, longer context, more tool-call accuracy, fancier planning loops. Almost none of it has gone toward containing what an agent can do when it's wrong. The default posture across Cursor, Claude Code, Aider, Codex CLI, and the long tail of agentic IDEs is still: run as the user, with the user's permissions, inside the user's actual filesystem. The sandbox is the developer's laptop, which is to say there is no sandbox.

Compare this to literally any other category of software that executes untrusted instructions. Browsers run JavaScript in a process-isolated, capability-restricted sandbox that took twenty years to harden. Container runtimes exist specifically to limit what code can touch. Even `make` has `--dry-run`. Yet we hand LLMs — which are, by construction, non-deterministic systems that occasionally produce confidently wrong tool calls — direct shell access to the same environment where our SSH keys, AWS credentials, and uncommitted work live. Anthropic's own Claude Code documentation now leans heavily on `--dangerously-skip-permissions` warnings precisely because people kept turning the permission prompts off to stop the friction. The friction is the feature.

The community response is splitting into two camps. One camp says the answer is better tooling: ephemeral VMs per task, container-per-session models like Apple's new `container` tool, devcontainers, or worktree isolation with explicit allowlists. The other camp says the answer is cultural: stop treating agents as junior engineers you trust, start treating them as untrusted code execution — because that's what they are. Both camps are right, and the industry needs both. What it doesn't need is another round of "we improved the system prompt to discourage destructive actions," which is the agent-safety equivalent of putting a sign on a loaded gun.

There's also a quieter point worth making: the open-source maintainer time absorbed by these incidents is uncompensated externality. When a Fedora packager spends four hours undoing an agent's mess, that's four hours not spent on actual packaging. Multiply by every distro, every upstream, every solo maintainer who tried Cursor last week. The agent tooling vendors are extracting productivity gains while the cleanup cost lands on people who never agreed to be the QA team.

What this means for your stack

If you ship code and use an agent, you have homework this week. First: audit what your agent can actually reach. Run it in a freshly cloned worktree, not your main checkout. Use `git worktree add` — it's been in git for a decade and almost nobody uses it. The blast radius of a worktree is the worktree; the blast radius of `~/code/myrepo` is everything you own.

Second: stop running agents with your real shell. The Claude Code CLI, Cursor's agent mode, Aider, and Codex CLI all support running inside a devcontainer, a Docker container, or a VM. Apple's `container` tool ships a hypervisor-per-container model on Apple silicon — use it. On Linux, `podman` or `firejail` will get you most of the way. The performance hit is negligible for the kind of work agents do; the safety delta is enormous. If your agent can `rm -rf ~/`, it will eventually `rm -rf ~/` — not because the model is malicious, but because probability is patient.

Third: separate credentials. Your agent should not have ambient access to your production AWS profile, your npm publish token, or your GitHub PAT with `repo` scope. Use a scoped token, mount it only into the sandbox, rotate it weekly. Treat the agent like a contractor: scoped access, audit log, time-boxed credentials. This is basic security hygiene that we somehow forgot the moment the editor got a chat panel.

Looking ahead

The next 12 months will sort agent tooling into two categories: tools that take containment seriously, and tools that don't. The ones that don't will keep generating LWN articles, Hacker News threads, and quiet Slack messages from maintainers explaining why a PR is six hours late. The interesting bet isn't on which model is smartest — it's on which agent runtime makes destructive actions structurally impossible rather than merely discouraged. Sandboxing is the unsexy infrastructure layer that will decide which of these products survive contact with real codebases. Fedora just gave the industry a free post-mortem. Read it before your laptop becomes the next one.