Let Your AI Agent Run Code — Without Handing It Your Whole Laptop

Here is the part of AI agents nobody puts in the demo: when you let an agent “run this code,” it runs on your machine, with your files and your keys in reach. Most of the time that is fine. The one time it is not — a bad command, a poisoned dependency, a prompt-injection that tells the agent to read ~/.ssh — there is nothing between the model and your laptop.

The fix is a sandbox: a sealed room where the agent’s code runs, isolated from your real files. In the reel I ran untrusted code inside one live and showed my laptop stayed untouched. Here is the tool and the exact setup.

The tool: OpenSandbox

OpenSandbox (Apache-2.0, ~13,900 stars) is a “secure, fast, and extensible sandbox runtime for AI agents.” It was open-sourced by Alibaba’s team and is now run as a community project under the neutral opensandbox-group org. It gives you Python / TypeScript / Go / Java / C# SDKs, an osb CLI, an MCP server, and both Docker and Kubernetes runtimes — so an agent can execute code, read and write files, and run a shell, all inside a container it cannot escape.

One honest note up front: the project markets strong microVM isolation (gVisor / Kata / Firecracker). Those are real options, but the simple local setup below runs on plain Docker — Linux container isolation (separate namespaces, dropped capabilities, no-new-privileges), inside Docker Desktop’s VM. That is genuine isolation from your files and it is what makes the demo work; it is not a microVM unless you configure one. I would rather you know exactly what you are running.

Run it locally (free, no cloud, no Kubernetes)

You need Docker Desktop running and uv (a fast Python tool runner). Then:

# 1. install the CLI
uv tool install opensandbox-cli

# 2. create a config that uses the Docker runtime
uvx opensandbox-server init-config ~/.sandbox.toml --example docker

# 3. start the sandbox server (leave it running)
uvx opensandbox-server
# → listening on http://localhost:8080

That is the whole install — no account, no API key, no cloud.

Prove the isolation in 60 seconds

In another terminal, create a sandbox and run some deliberately nosy code inside it:

# spin up an isolated python environment
osb sandbox create --image python:3.12

# ask it to write a file and try to reach the host — inside the sealed room
osb command run <sandbox-id> -- \
  sh -c "echo pwned > /root/OWNED.txt && cat /etc/hostname && ls /root"

The code runs — it writes OWNED.txt and lists files — but only inside the container. Now look at your real machine:

ls ~            # no OWNED.txt here
cat ~/secret.txt   # still exactly as you left it

The agent’s code executed fully, and your laptop never saw it. That is the money moment: the room is sealed, so it does not matter what runs in there.

When you actually need this

• You are letting an agent (Claude Code, an autonomous loop, a “computer use” tool) run shell commands or generated scripts.
• You are running code from an untrusted source — a gist, a model’s output, a dependency you have not read.
• You want a throwaway environment per task that you can destroy and recreate instantly.

The honest limits

• Root inside the container is still root inside the container. The point is not that the code is powerless — it is that its power is trapped in the namespace and cannot reach your host files.
• Plain Docker is strong, not infinite. Container escapes exist. For genuinely hostile code, configure one of the microVM runtimes the project supports (gVisor / Kata / Firecracker) — that is a stronger boundary at the cost of setup.
• It needs Docker running. This is not a pure-userspace tool; the isolation comes from the container runtime underneath.

The rule of thumb: never let an agent run code where it can see your keys. A sealed room costs one docker-backed process and buys you the ability to say yes to “run it” without flinching.