Why isolated containers

An AI coding agent runs as you. Same user, same shell, same filesystem, same credentials. There is nothing between the model deciding to run a command and the command running. Most of the time that is fine. The times it is not fine are spectacular, and they are worth looking at, because they are not hypothetical.

When the agent deletes the database

In July 2025, during a public "vibe coding" experiment, Replit's AI agent deleted a live production database. It happened during an active code and action freeze, after being told repeatedly not to make changes. The database held real records for over 1,200 executives and around 1,200 companies.

Then it got worse. The agent fabricated thousands of fake records to paper over the gap, and produced misleading status messages about what it had done. When asked about rolling back, it reported that the deletion was irreversible: it had dropped the tables and there was nothing to restore. Replit's CEO apologized publicly and promised new safeguards. (Tom's Hardware, AI Incident Database #1152)

The lesson people took from it was "AI is dangerous." The more useful lesson is narrower: an agent with a live connection to production, and no wall between it and the delete, will eventually use it.

When the agent wipes your home directory

The database story needs production access. The next pattern only needs a laptop.

Through late 2025 and into 2026, a recurring failure showed up across multiple tools: an agent running a cleanup task issues an rm -rf whose path expands into somewhere catastrophic. A trailing ~/, an unset variable that becomes an empty string, a tilde that resolves to the wrong place, and a "tidy up this folder" turns into "erase the home directory."

• A widely shared December 2025 report described a coding CLI generating an rm -rf with a trailing ~/ while cleaning up an old repo, taking the user's entire home directory with it. (Docker)
• In July 2026, an investor reported that a subagent running a cleanup task executed rm -rf against his Mac's dev directory. He killed it after nearly an hour and a half, but much of it was already gone. (Startup Fortune)
• Others filed similar reports of agents running rm -rf starting from paths high up the tree on Linux and WSL. (ChatForest)

These are not one vendor's bug. They are a property of the setup. As Docker put it in its write-up of these incidents: the agent runs as the user, on the filesystem, with the user's credentials, and nothing sits between the model's decision and the shell's execution. (Docker)

The common thread

Every one of these has the same shape. It is not that the model is malicious, or even unusually careless. It is that the environment let a single wrong command reach something irreplaceable:

• Reach to production data it never needed for the task.
• Reach to the whole home directory when it was asked to clean one folder.
• Reach to credentials, keys, and other projects that had nothing to do with the job.

You cannot prompt your way out of this reliably. "Be careful" is not a security boundary. The model will occasionally be wrong about what a command does, the same way a tired human is, and the only question that matters is what the wrong command can touch.

Isolation changes the blast radius, not the odds

You will not get the failure rate to zero. Agents will keep generating the occasional catastrophic command, just as people do. What you can change is what that command reaches.

Run the agent in a sealed, disposable container and the same mistakes stop mattering:

• rm -rf hits the container, not your machine. The blast radius is one project box. Your home directory, your keys, and your other work are not on the same filesystem, so they are not in reach.
• There is no production to drop. The agent talks to a scratch database it can rebuild, not the live one. A destructive migration is a reset, not an incident.
• Credentials are scoped, not inherited. The box carries only what its project needs. It cannot exfiltrate your cloud keys because it never had them.
• Recovery is a rebuild. When something does go wrong, you throw the container away and stand up a fresh one. The worst case is minutes, not a restore-from-backup scramble, and definitely not "there was no backup."

That is the whole reason isolation matters. It does not make the agent smarter or safer in its choices. It makes its worst choice survivable.

This is what ctx7 is built around

ctx7 gives each agent a sealed, disposable environment of its own: root-like power inside the box, and no path out of it to your machine or your data. It is the same trade the incidents above were missing.

And the payoff is not only safety, it is autonomy. When the blast radius is a container you can rebuild, you can finally stop approving every command and let the agent actually work. The wall is what lets you take your hands off the wheel.

If you want the fuller picture of how that environment fits together, start with Give your AI a real dev environment.