Every AI coding agent ships with the same warning label: this tool can execute arbitrary code on your machine.

Claude Code has --dangerously-skip-permissions. Codex runs in a sandbox by default and makes you opt out for full access. The naming is intentional — it’s supposed to make you pause. And it should, if the agent is running on your laptop alongside your SSH keys, your credentials, your photo library, and that .env file with production database access.

But here’s the thing: agents with permissions are dramatically more useful than agents without them. An agent that can install dependencies, run your test suite, start a dev server, and iterate on failures without asking you to click “allow” forty times — that’s an agent that actually finishes work. An agent in a permission straightjacket produces suggestions, not solutions.

The answer isn’t braver developers. It’s better sandboxes.

The permission paradox

Watch someone use Claude Code for the first time. The first five minutes are a negotiation:

“Claude wants to run npm install. Allow? Claude wants to create a file. Allow? Claude wants to execute a shell command. Allow?”

Most developers quickly reach for --dangerously-skip-permissions because the alternative is babysitting every syscall. The agent goes from collaborator to interruption machine without it.

But running --dangerously-skip-permissions on your personal machine means the agent has the same access you do. It can read any file. It can run any command. It can rm -rf your home directory if a prompt injection slips through. It probably won’t. But “probably” isn’t a security model.

This creates a paradox: agents need full permissions to be useful, but your laptop is the wrong place to grant them.

The fix is obvious once you say it out loud. Don’t run agents on a machine you care about. Run them on a machine that exists purely for them to run wild in.

A VM you’d hand to a stranger

Imagine a machine where you genuinely don’t care what the agent does. It can install anything, delete anything, break anything. If it trashes the environment, you spin up a new one. If something goes sideways, nothing else is affected — no other projects, no personal files, no credentials for systems the agent has no business touching.

That’s a Firecracker microVM. Its own kernel, its own filesystem, its own network. Not a container sharing a kernel with everything else on the host. A real virtual machine with real isolation, where “dangerously skip permissions” stops being dangerous because the blast radius is one disposable environment.

This is the primitive that makes agents practical, not as a matter of computing power — your laptop runs these agents fine — but as a matter of trust boundaries. You need a machine where the answer to “should the agent have permission to do that?” is always yes, because there’s nothing outside the sandbox it can damage.

Accessible from everywhere, running nowhere when idle

There’s a second problem with local agent workflows that has nothing to do with safety: they’re anchored to one machine.

You start a session on your work laptop. You want to continue on your personal machine at home. Or check on progress from your phone. Or hand the environment to a teammate so they can pick up where you left off. On localhost, none of this is possible without tunneling hacks or pushing half-finished work to a branch.

When the environment is a cloud VM behind a URL, it’s just a browser tab. Open it from anywhere. Close it and walk away. The state persists — agent history, installed packages, file changes, everything.

And when nobody’s using it? The VM snapshots and sleeps. Zero cost. Zero resources consumed. Next time someone opens the URL, it wakes in under a second, exactly where it was. You don’t pay for a machine that’s waiting for your next idea, and you don’t leave a process burning electricity on your desk overnight.

This isn’t about replacing your laptop. It’s about having a workspace that exists independently of any specific device — one that’s always there when you need it and costs nothing when you don’t.

Multiple agents, one sandbox

The multi-agent story gets interesting here.

Claude Code, Codex, and OpenCode each have different strengths. Different models, different approaches, different blind spots. Using one agent is an assistant. Using three against the same codebase — same files, same dependencies, same project state — is a design tool. Draft with one, critique with another, refactor with a third. The disagreements between agents tell you where the real design decisions live.

This works because the agents share a persistent filesystem. When Claude Code installs a package, Codex sees it immediately. When OpenCode modifies a file, Claude Code’s next response reflects the change. No syncing, no re-cloning, no context drift. Just three perspectives on one codebase, operating in the same environment a human developer would use.

Each agent runs fully unshackled inside the VM. Full root access. No permission prompts. Because the sandbox is the safety mechanism, not the agent’s own permission system.

The infrastructure you don’t have to build

There’s a narrative forming in the industry that says developers need to “standardize their development environments” before they can use agents effectively — that it requires a platform team, Terraform modules, and months of infrastructure work.

That’s true if you’re running a fleet of background agents across a monorepo at a company with a thousand engineers. It’s not true if you’re a developer who wants to use AI coding agents without compromise.

What you actually need is simple: an isolated VM, agents pre-installed, a browser to access it, and economics that don’t punish you for not coding 24/7.

Not a platform to build. Not an infrastructure project to staff. An environment that shows up ready, runs your agents without restriction, sleeps when idle, and doesn’t touch anything outside its own walls.

That’s what we built.