A Sandbox for Claude Code: Isolated Agent Environments on a Laptop

When a reboot wipes your working memory

Picture six or seven Claude Code sessions open at once. A few sit in terminals, a couple live inside VS Code, one runs in IntelliJ because the team works in several languages and each has its favorite editor. They touch different repos, different tasks and different half-finished thoughts. Then the laptop restarts.

Nothing is wrong with the code itself. The loss is the position of everything: which session was mid-refactor, which one awaited a build, which one had posed a question whose answer was never read. Twenty minutes go to reconstructing working memory from shell history and dirty git branches. At that point a bad day starts to look like a design problem.

The reboot was only the loudest symptom. Three separate frictions were wearing things down.

Shuffling. Agents are cheap to launch and costly to keep track of. Each new one needs another terminal tab, another editor window, another slot in your head. The laptop turns into a pile of windows with a human as the only integration layer. Existing tooling assumes one agent, one task and one person watching, which isn't how the work is going.

The permission dilemma. Nothing in the default setup resolves this one. Claude Code wants approval for tool calls, yet it may query you over something minor while staying silent about a call that could do real damage. Behavior has gotten better, but the core issue is unchanged, since the agent acts as you and holds your privileges. A GitHub org admin can't sensibly sign off on every API call, and can't pretend a single sign-off is harmless either.

Two paths remain. You can keep tuning an allow-list until it grows into a private artifact no colleague could decipher, or you can turn on --dangerously-skip-permissions and trust luck. The horror stories come from that second path, like the agent that eagerly cleaned up a production database. Both fail for one reason: the agent carries your identity, and approving commands one at a time only works around that.

Install fatigue. Several repos on several stacks bring a missing JDK, the wrong Node, this SDK, that CLI and a version pin set up half a year ago that nobody can explain anymore. Every context switch carries a tax paid in minutes of watching a package manager. It compounds when a laptop is lost or replaced, since each environment has to be rebuilt tool by tool. After months of tuning a favorite coding CLI, it's an open question whether the configuration could be reproduced at all or whether you'd start over and hope to remember the important parts.

A machine of its own for the agent

It didn't start as a platform project. Capsule was a personal tool, built to make one engineer's week less annoying. The premise was simple: give the agent a machine of its own, not yours, where it can't see your filesystem or use your credentials and where saying "go ahead, don't ask" isn't reckless. It also had to be cheap enough to create that several could run side by side with no thought.

Coworkers noticed and asked for their own, then others did too. It outgrew its origins as one person's tool and now opens on a growing number of engineers' screens each morning, going from a few early users to a few dozen, with much of the engineering group plausibly next. No one is pushed to use it. People adopt it because the week gets easier, the only signal of adoption worth believing. A new hire installs Capsule on a laptop and can work fully agentically from the first day.

In a single sentence, Capsule hands Claude Code a secluded, ready-made sandbox where it can work on your repos on its own, so it no longer runs with your full set of privileges.

The picture shows Capsule Station. Capsules are listed along the left edge, the chosen agent's terminal occupies the center, and the pull requests you own or were asked to review are at lower left, giving one window for the whole fleet.

Its scope is narrow on purpose. It isn't an agent-orchestration framework or multi-agent product, for now anyway, although some orchestration might appear soon. It isn't an IDE, plugin or editor integration, and it doesn't fork or replace Claude Code, because what runs inside is plain Claude Code configured a certain way. It doesn't stand in for CI/CD, and it isn't hosted SaaS, since everything happens on your laptop.

That final point proved more important than expected. No per-seat charge and nothing to run means a tenth capsule costs the same as the first, which turns parallel work from a luxury into routine. The machine is already paid for, and repositories stay on the hardware where they started.

Inside a capsule, Claude runs with --dangerously-skip-permissions and never asks whether it may execute a command. Its only questions concern intent, meaning what to do, and never permission. That's a sane default only because of two things underneath.

The sandbox

Every capsule runs as a pod in the Kubernetes cluster that OrbStack already provides on the Mac. That keeps it all local, with no added infrastructure and no cloud bill. The host filesystem can't be reached, and two declared volumes hold persistent data: a workspace and a Docker image cache. Three layers restrict outbound traffic:

• Kernel iptables rules block direct outbound ports 80 and 443 for the agent's user ID.
• A Kubernetes NetworkPolicy narrows what's left to DNS, 80 and 443.
• Whatever survives goes through a Squid proxy that enforces an explicit domain allow-list.

The allow-list covers GitHub, npm, Maven, ECR and the Anthropic API, and every other destination is denied by default. An agent has no easy way to reach an arbitrary endpoint and upload your source, and getting there would take real ingenuity.

Three layers say no before anything leaves: kernel rules, then network policy, then the allow-listing proxy.

Least-privilege credentials

Here's where the real value lies. Authentication happens on the host under your own name, with every role you usually have. Those roles stay in the macOS keychain and never reach the capsule. What the host does instead is create a narrowly scoped, short-lived token and inject that:

• a temporary AWS STS credential limited to a read-only production role
• a GitHub token, with its scopes verified before it goes in
• a read-only BigQuery service account that the agent impersonates, so your own credentials stay out of it

Supply something wider, like an SSO production-admin role or a token with excess scopes, and the host declines to inject it at all. Defense is the default, and from inside, the agent has no way to re-authenticate or federate into broader access. Identity is preserved, so the audit log still attributes the query to you, but what can be damaged is limited to the role and doesn't extend to you.

You log in as yourself on the host, and the agent only ever receives a narrow, short-lived token minted from that. This trade makes everything else work. Letting an agent run unattended doesn't rest on trusting it more. It rests on making the worst case boring.

Removing friction

Security buys permission to be autonomous, but it doesn't make the experience good. Most of the effort went into removing friction.

The base image that capsules boot from already carries pinned versions of the toolchain: Go, Rust, Node, the JDK, Maven, sbt and Scala. Alongside runs a Docker-in-Docker sidecar, which gives each capsule its own working Docker, so integration tests and Testcontainers suites execute without touching neighbors. Logged-in command-line tools are waiting too, namely the GitHub CLI, AWS CLI, gcloud and bq. Out of the box there are language servers (Metals, jdtls, gopls, rust-analyzer, vtsls), which lets the agent move through code by symbol with go-to-definition, find-references and call hierarchies instead of grepping blindly.

Caches for dependencies are shared among capsules via a host volume. It reads like a minor detail but isn't. In the first version every new environment downloaded everything again, and a tool that spends twenty minutes on Maven before each task won't be adopted. Now a warm capsule is up in roughly twenty to thirty seconds.

What changed the agent's behavior most was a genuine feedback loop. An internal platform CLI runs within the capsule: the host's SSO token is checked, limited in scope and injected, allowing the agent to create a sandbox environment, deploy the branch it has just built and run smoke tests there. The integration-test harness also runs inside, pulling real images and starting actual MySQL, Kafka and Cassandra in the sidecar. Slow at first while images pass through the proxy, it's warm afterward. That separates an agent producing plausible code from one able to report if the code works.

Lookup ability is built in as well. Every capsule starts with an internal MCP gateway that only reads, offering a few dozen tools. They reach logs from services and pods, metrics through PromQL and Thanos, Grafana dashboards, Kubernetes events, status of CI builds, who's on call and what alerts are firing, service ownership, and search over Confluence and Slack. Since nothing can be written, switching it on everywhere carried no risk. A plugin marketplace adds team skills for Maven builds, service scaffolding, sandbox management and PR review, so house conventions are familiar to the agent from the first minute.

Here's a habit worth adopting. Keep a private repository holding personal slash commands and plan templates, and Capsule will clone it into each environment created. Your own workflow therefore follows you. Plans and memories also move between capsules through that repo, and a handover skill can note where a session ended and file the summary, so the next capsule starts with context and not from zero. It's an ordinary git repository, so the agent can maintain its own tools as well, and one instruction like "add a build-and-test command, commit it, push it" is enough.

Parking beats starting

An unplanned effect followed. Once creating an isolated agent is cheap and each one persists whether or not anyone is watching, work stops being one thing at a time.

On a typical afternoon, four or five capsules are active. One works headless on a bug fix, one is an SSH session for real pair programming, one reruns a flaky integration test and opens a pull request when it passes, and one grinds through a dependency bump nobody wants to watch. Roughly ten more sit stopped: an idea to return to, an experiment that failed in an interesting way, a design half-considered. Stopping keeps repos, sessions and caches, and resuming takes seconds, so a line of thought isn't abandoned just because it isn't today's priority.

The expensive part was never starting work. It was parking it. And when something is finished, you delete the capsule, with no git worktree mess and no cleanup chores, and all by-products vanish together.

Full autonomy erases the remaining friction. There's no approval prompt for a git command, no digging through a browser tab for a number on a CI page and no combing a build log for the one line that counts. The agent handles it, and with the sandbox and scoped tokens in place, allowing that doesn't amount to simply gambling.

Four capsules, four states, none waiting on the human.

There are two modes on a single engine. You can work beside the agent in an interactive tmux session, or give it a prompt and leave it be.

That's the reason the interface counted. The CLI was strong, yet running list, ssh and status again and again in a terminal is no way to manage a fleet. Capsule Station fills the gap with a single window: capsules in a sidebar, an embedded terminal for each, and your pull requests and review requests alongside. Switching agents feels like switching browser tabs. The app uses Tauri, weighs about ten megabytes and relies on the system webview, because displaying a list shouldn't demand a bundled Chromium and a gigabyte of disk. It tends to stay open all day while the IDE rarely does.

It's equally fair to say what it leaves untouched. The quality of generated code doesn't improve. What goes away is the toil around it: shuffling, approving, installing, re-authenticating and losing your place, which turned out to be most of the friction.

Why build instead of buy

Hosted options are real and increasingly good, such as cloud agent sandboxes from several vendors and agents running remotely for you. They bring no operational burden and real scale. But code and credentials leave your perimeter, toolchains are generic and so cold starts drag on a large codebase, and an internal identity model can't be expressed. Open source projects exist too, like Kubernetes-native sandboxes, dev-container tooling and the local sandboxing primitives that model vendors provide. They're vendor-neutral and built on firm primitives, yet low-level, leaving you in charge of the image, authentication and the whole user experience. For any option, a fair worry is whether it's still maintained in six months, since everyone is launching an initiative and few will last.

Building sat between the two. Capsule is largely composition, with DevPod handling the dev-container and pod lifecycle, Squid handling egress, the Kubernetes cluster that OrbStack already supplies, and then a custom workspace image, host-mediated auth and Station as the top layer. Lock-in stays shallow and parts can be swapped out. It suits the codebase and authentication model, and code remains on the laptop apart from what the agent sends to the model API, as with every option here.

Credentials are minted on the host, while everything the agent touches runs in a pod behind a proxy with an allow-list.

There's also a flexibility argument that turned out to matter more than expected. If someone wants a feature, they open a pull request and discuss it, and it ships. Nobody spends three weeks with a product manager explaining that it might make next year's roadmap.

The risk is real and worth stating: the team owns it, and it's essentially a one-person project with company backing. Development has never been cheaper, and maintenance cost is the real unknown. Nobody has that answer yet.

What comes next

Ahead lie a broader rollout from dozens of users toward the whole organization, more skills and tools baked into the image, and more integrations. That last item is harder than it sounds, since each one needs an answer for what an agent in no-questions-asked mode can do with it. Read-only access is easy, but anything that writes calls for a serious discussion and a way to mark destructive operations. Remote operation is the most requested feature by far, so capsules would keep running with the laptop closed.

A warning about security gaps

The system is defensive deliberately, and building it brings an uncomfortable lesson: a tool granting agents autonomy leans hardest on the weak spots of a security model. Good access control makes integration easy, while its absence hurts right away and shows exactly why.

Even so, a sandbox has limits. Running an agent with full privileges is like carrying loaded guns, fired or not. Capsule removes them. Paste an admin token into the chat and tell the agent to use it, though, and they've been handed back.

Go build

These are remarkable times, and it's hard to overstate what one engineer can build. This started as a single person's annoyance on an ordinary afternoon and became something that a growing number of coworkers open each morning. Two conditions remain. You must know which problem you want solved, and you need backing, since tokens cost money and someone has to agree they're worth it. With both, the job has changed permanently, so find the problems and fix them.