User amedeos released the open-source project another-ai-sandbox — a set of rootless containers on Podman that isolates AI coding agents from the host file system. The project was created as a response to an incident where Claude Opus 5 wiped a user's disk with an rm -rf command while performing a backup task.
What happened
The another-ai-sandbox project (GPLv3 license, 40 commits) implements isolation of AI coding agents through rootless Podman containers. Each agent — Claude Code, OpenAI Codex, Cursor Agent, and opencode — runs in a separate read-only container based on Fedora 44 with minimal capabilities. By default, resource limits are applied: 2 CPU, 4 GB RAM, 512 PID. Network isolation is provided through pasta/slirp4netns. An optional command blocker based on eBPF LSM allows blocking specific commands from inside the sandbox, for example, blocking git push. Installation is done with a single install.sh script that checks dependencies, builds images, and installs the ai-sandbox CLI.
Context
The incident where Claude Opus 5 wiped a user's disk with an rm -rf command while performing a backup task received wide resonance: discussion on r/ClaudeAI gathered 2300+ upvotes in three days. Similar incidents were recorded with Codex GPT-5.6, which also deleted user directories. These cases confirmed that permission prompts and deny lists do not provide structural protection: this is an architectural gap that cannot be closed with prompting. Container isolation with rootless containers and limited mounts became the approach on which the community converges as the only reliable way to protect.
Why this matters for the industry
Incidents of destructive agent actions create structural demand for AI agent security infrastructure. another-ai-sandbox demonstrates that the rootless containerization pattern solves the problem where permission prompts are powerless, and sets a ready-made architectural scheme for safe execution. This creates a category of AI agent safety in which a business can be built: from SaaS wrappers to enterprise solutions. It is expected that vendors — OpenAI, Anthropic, Cursor — will natively integrate container isolation into their products, and eBPF blockers will be expanded into formal policy languages. Container isolation may become a de facto standard for any AI agents with shell access.
Why this matters for users
Developers running Claude Code, Codex, or Cursor Agent locally get a ready-made solution: one install.sh checks dependencies, builds images, and installs the CLI, after which the agent only sees the directories that are explicitly mounted. The optional BPF blocker allows blocking specific commands — git push, curl, rm — directly inside the container. The project works on Fedora, Arch, Debian 12+, and Ubuntu 24.04+. Five supported agents in one project lower the barrier to entry for safe use.
What is still unknown / limitations
The project is at a very early stage: 40 commits, one author, lack of CI/CD, tests, monitoring, and documentation on fault tolerance. There are no security benchmark tests, in particular tests for adversarial escape from the sandbox. The project is not ready for production deployment. The architectural pattern can be adapted, but the ready-made solution requires reliability testing before use in critical scenarios.
Sources
- amedeos/another-ai-sandbox — GitHub project repository
- Claude rm -rf Incident: Why Agents Still Delete Drives — explainx.ai
- Rootless Container Sandbox for Claude Code and Codex — Hacker News
Author
Look at AI, editorial team