A Rust sandbox lets coding agents work without touching your real project

The problem with a bare shell

AI coding agents can do more than suggest code. Many of them run terminal commands, edit files, install packages and launch scripts. As dev.to reported, a developer who goes by the project name ShadowCLI argues that this is risky when it all happens directly on your own machine.

The worry is simple. A shell started by an agent usually acts with your permissions. The post lists the things that could go wrong: project files wiped, a .env settings file overwritten, SSH keys or cloud credentials read, Git history changed, an untrusted install script run, or unexpected connections made to the internet.

The author's point is that a pop-up asking "allow this command?" is not enough. People click through prompts, and a single approved command can still do broad damage. So the post proposes a hard boundary instead of a polite question.

How the sandbox is put together

ShadowCLI is a command-line tool for Linux. You put shadow run in front of a command, and that command executes inside an isolated environment instead of directly in your project folder.

The edits it makes are written to a temporary copy-on-write layer. That means the original files stay untouched, and only the differences are recorded on the side. The post names OverlayFS and CopyFS as the pieces that do this.

The isolation itself is built from several Linux features stacked together:

• User namespaces give the sandboxed process its own set of user and group identities.
• Mount namespaces give it a private view of the filesystem.
• PID namespaces keep its processes separate from yours.
• Network namespaces cut off outbound network access by default.
• Landlock, a Linux security module, restricts which files the process may touch.
• Seccomp BPF blocks certain risky system calls, the low-level requests a program makes to the operating system.

The idea is defense in depth: if one layer has a gap, another may still hold.

Running a command, then deciding what to keep

The most useful part is the review step. Running a command and accepting its results become two separate decisions. After an agent finishes, shadow diff shows what changed, and shadow diff --stat gives a short summary. shadow review lets you go through the modifications interactively.

When you are happy, shadow apply --all --yes copies the approved changes into your real project. If you regret an apply, shadow apply --rollback undoes the most recent one. If you don't like what the agent did, shadow discard throws away the unapplied changes.

Other controls are plain. Network access stays off unless you add --allow-network, for example for a build that must download packages. A --timeout option, shown with 30 as an example, stops a command that runs too long. Before any of this, shadow doctor checks whether your system supports what the tool needs, including user namespaces, Landlock, Seccomp and the filesystem features.

Which agents it could wrap

The author describes ShadowCLI as a general boundary for any tool that runs terminal commands, not a feature of one product. The post names a long list of possible targets, including Claude Code, OpenAI Codex, Aider, OpenHands and Cline, plus custom-built agents. One example wraps a terminal agent by launching it as shadow run -- aider. Another shows a Python script calling the tool through its subprocess feature.

There is a caveat. How well it works with a given agent depends on how that agent touches files and starts other programs. The post does not claim every agent will behave properly inside it.

Setup is manual. You clone the repository from GitHub, build it with Rust 1.80 or later, and copy the resulting binary to a folder on your path.

What it does not promise

The author is open about the limits. This is not a stand-in for a proper security review, for backups, or for a hardened virtual machine, which is a fully separate simulated computer. How well it protects you also depends on your kernel, your filesystem, your settings, and whether the isolation code itself is correct.

That last point matters. This is a young open-source project, and the author is asking developers with Linux, kernel security and sandboxing experience to read the code and report problems. Nothing in the post suggests an independent audit has been done.

Still, the habits it encodes are sound whatever tool you use: give the agent a throwaway working copy, keep your credentials out of reach, block the network unless needed, and look at the changes before you accept them.