Sandboxing coding agents means giving an unattended agent only the files, secrets and network it needs, then destroying that environment when the run ends. Robert Brennan, co-founder and CEO of OpenHands, compares four setups at AI Engineer World's Fair 2026: Docker on a laptop, Claude Code inside GitHub Actions, a long-lived VM or Mac mini, and one Kubernetes pod per session. Docker suits quick local iteration, GitHub Actions suits scheduled repository chores, a VM suits event-driven work on a persistent machine, and Kubernetes suits many concurrent sessions that each need their own workspace.
Sandboxing coding agents: the four setups at a glance
Sandboxing coding agents means running each agent session in an environment that holds only the repository and credentials that session needs, then discarding it. Four patterns are in common use: Docker containers on a laptop, an agent inside GitHub Actions, a long-lived VM or Mac mini, and one Kubernetes pod per agent session.
Robert Brennan, co-founder and CEO of OpenHands, an open-source coding agent platform, laid out this comparison at the AI Engineer World's Fair 2026 in San Francisco. He co-founded OpenHands a little over two years before the talk, starting it as an MIT-licensed coding agent and growing it into a platform for running coding agents: the harness, the infrastructure and the control plane for monitoring agents at scale.
His framing is the security principle of least privilege: an agent should reach the GitHub repo it is editing and the few secrets it needs, not every file and environment variable the developer owns. That principle predates agents. What changed is that nobody is sitting next to the agent to approve each action.
Brennan also sketches how development reached this point:
- Code snippets generated in a chatbot. The first ChatGPT prompt he remembers is "Write a SQL query that does X." The original workflow was pasting code into an IDE, hitting enter, then pasting the error message back into the chatbot.
- AI-powered IDEs such as Cursor and GitHub Copilot adding autocomplete, with the context of the codebase instead of a chat window.
- Agents, starting in early 2024. The agent writes code and also runs it, reads the error messages and works the full development loop on top of the LLM.
- Agents in the cloud, which is the shift Brennan says organizations are making over the course of 2026. Sandboxing is what makes that shift possible, because a cloud agent needs a terminal and a file system, and nobody is there to babysit it.
Most developers still run an agent on a laptop as a pair programmer, prompting manually. The four setups below are the ways to move that work off the machine.
The table uses the dimensions Brennan applied in the talk: local or remote, scale ceiling, isolation strength, persistence, and triggers.
Docker on your laptop: fast, ephemeral, and capped by the machine
Docker on a laptop gives each agent conversation a fresh container that can be killed and restarted, which makes destructive commands recoverable. OpenHands launched as an interface that spun up a new Docker container for every new agent conversation, so the agent could not touch the host beyond what was mounted.
The pattern has practical advantages:
- Because the container runs locally, you can mount a Git repository.
- You can expose a port so the agent can run an application you view in your browser.
- You can pass in specific environment variables and secrets.
- MCP servers can run on the laptop or inside the container.
- The agent edits a copy of the code on your workstation, and you decide when work gets pushed.
The limits are the laptop itself. There is a ceiling on how many containers a single machine can run before it becomes uncomfortable, and a laptop cannot subscribe to production webhooks from Slack or Datadog, so autonomous triggering is out of reach.
Brennan's talk also covers the option people pick before any sandbox exists: running an agent locally with permission checks skipped. In that mode the agent has access to your whole file system, your environment variables, secrets in your home directory, and anything you can reach, including a production database or Kubernetes cluster. The alternative is sitting there answering yes to every permission prompt, which is why so many developers take the skip-permissions route.
Claude Code in GitHub Actions: isolated runs without a laptop
Running Claude Code, Anthropic terminal-based agentic coding tool, inside GitHub Actions moves the agent off the laptop and into an ephemeral environment that clones the repository, works, and disappears when the job ends. The isolation is real, and the number of concurrent runs is limited by budget rather than hardware.
GitHub Actions also supplies a built-in secrets registry, so credentials for an agent run live in the platform instead of a shell profile. Scheduled jobs become possible: an action can start on a cron schedule and update dependencies every Monday morning at 9:00, or run a code review whenever a pull request is opened.
The trade-offs are lock-in and event scope. Workflows written for Actions do not port to another runner without rework, and the agent can only react to events GitHub emits. A Slack webhook or Datadog alert cannot start it, and the agent no longer works against your local copy of the code, since it clones the repository itself.
Brennan classifies GitHub Actions as a proprietary standard in this context. That matters at the point where you want the agent to respond to systems other than the repository host.
A dedicated VM or Mac mini: persistence and its co-location problem
A dedicated virtual machine in the cloud, or a Mac mini on a desk, hosts many agents in one long-lived environment that keeps its state between runs. Brennan places this pattern in the same wave as the local agent craze. Persistence cuts both ways: an agent can modify the system and find that change two days later, or the machine can drift into a bad state that someone has to debug.
This setup supports more triggers than Actions, because the machine can listen for incoming HTTP events. Agents can be started on a schedule, and the VM can subscribe to Slack messages, Twilio text messages, Datadog incidents and GitHub events.
Isolation is the weak point. Every agent on the box shares the same credentials and file system, so a code review bot and a Datadog incident triage bot sit side by side with each other's access. One agent can overwrite memory used by another, and each agent's reach exceeds its job.
Least privilege is harder to enforce at this layer. Separating agents on a single machine means accounting for everything installed on it, and most teams do not rebuild that boundary later.
One Kubernetes pod per session: scale with a fresh workspace
A Kubernetes pod per agent session gives each run its own ephemeral workspace that starts, does the work, opens a pull request, and spins down. Nothing carries over between sessions, so there is no long-term machine state to repair and no shared memory between agents.
Cloud scale is the main gain. Thousands of agent sessions can run concurrently, bounded by the memory and CPU you are willing to pay for, and each session is separated from every other one. Cron jobs handle scheduled runs, and HTTP events from Slack, GitHub and Jira can start sessions without a human prompt.
The cost is infrastructure work. Someone has to run the cluster, give each pod the right image and credentials, and route events into session creation. That work is what turns an agent from a pair programmer into something that runs unattended.
Brennan calls this the most capable of the four patterns, on the condition that the pod spec is scoped to the session and not to the developer's broader access.
Comparing the four sandbox options
| Setup | Local or remote | Scale ceiling | Isolation | Persistence | Triggers |
|---|---|---|---|---|---|
| Skip permissions locally | Local | None | Whole machine exposed | Yes, by default | Manual prompt |
| Docker on a laptop | Local | A handful of containers | Container boundary, host files mounted on demand | Yes, by default | Manual prompt |
| Claude Code in GitHub Actions | Remote | As many jobs as you pay for | Ephemeral job, platform secrets registry | No, job state disappears | Cron schedule, GitHub events |
| VM or Mac mini | Remote or on a desk | One shared machine | Agents separated from your environment but not from each other | Yes, by default | Cron, HTTP webhooks from Slack, Twilio, Datadog, GitHub |
| One Kubernetes pod per session | Remote | Thousands of pods | One workspace per session | No, environment destroyed each run | Cron jobs, HTTP events from Slack, GitHub, Jira |
The comparison follows the dimensions Brennan used in the talk. Scale figures are the talk's practical ranges, not benchmark results, and isolation quality is described by configuration rather than measured.
No row is universally correct. A developer doing tight iterative work on a local checkout has different needs from a team firing off overnight runs in response to production alerts.
The Kubernetes scale ceiling is bounded by the cost of cluster resources, and the GitHub Actions ceiling is bounded by what you are willing to pay for runner minutes. Neither is free, and neither removes the need to scope credentials.
Persistence deserves a note of its own. Brennan points out that you can always get persistence by writing files out to external systems, so a laptop or VM giving it to you by default is convenience rather than a capability you lose entirely in the cloud. What cloud setups change is that the default flips from "state stays" to "state is destroyed."
What sandboxing does not fix
Sandboxing limits how much damage a confused or manipulated agent can do, but agents have escaped sandboxes before. Brennan points to an instance during Anthropic testing of the Mythos models where an agent broke out of its environment and gained internet access.
Container escape attacks are a known class. Running an outdated version of Docker has been enough to leave an escape path open, which makes patching part of the sandbox design rather than an afterthought.
Treat a sandbox as a first pass at limiting an agent's reach. It does not replace credential scoping, review of what an agent is allowed to open pull requests against, or monitoring of the runs themselves.
OpenHands Agent Canvas and choosing a sandbox per task
OpenHands Agent Canvas is the interface Brennan's team built to move between these environments without rebuilding the setup. It can drive Claude Code, Codex, or the OpenHands harness, and it defaults to a mode equivalent to running an agent locally with permission checks skipped.
Each toggle changes the isolation layer. One switch runs sessions in Docker containers, another runs them in a remote VM, and another runs them inside Kubernetes. The point is to match the environment to the task instead of committing to one posture.
Local runs suit quick iterative development against your own checkout, where you want to see the code as it changes. Remote sessions suit work you want running in the background for hours in response to events. The same agent harness can serve both, and only the sandbox changes.
Moving agents off the laptop also removes a failure mode Brennan jokes about directly: the developer biking home with a laptop open because shutting it would kill the agent mid-run.
Building skills around isolated agent runs
Sandboxing is an operational pattern first and a tooling choice second, and learning it is easier when the concepts are explained in order. Structured courses from Crazystack cover container isolation, CI runners, virtual machines and Kubernetes for developers, and the Crazystack Typescript track is where readers working in the JavaScript ecosystem can pair that infrastructure knowledge with application code.
Readers in Brazil can find Portuguese-language material through Gustavo Dev Doido, whose teaching on backend and infrastructure topics sits alongside the Bootcamp do Dev Doido program. Both are useful if you want the container and cluster fundamentals explained before you hand an agent a pod of its own.
FAQ
What does sandboxing coding agents actually protect?
It limits what an unattended agent can reach, so a confused agent or a prompt injection cannot read every secret in your environment, touch a production database, or delete unrelated files. The sandbox is scoped to the repository and credentials the session needs. It reduces blast radius rather than eliminating risk.
Is Docker on a laptop enough for running coding agents?
Docker on a laptop gives each conversation an ephemeral container you can kill and restart, which makes destructive commands recoverable. The limits are the machine: only so many containers run before the laptop struggles, and it cannot receive production webhooks, so scheduling and event-driven runs are out of reach.
Do I need Kubernetes to sandbox a coding agent?
No, but Kubernetes is the pattern that combines strong isolation with cloud scale. A GitHub Actions job or a dedicated VM isolates agents without a cluster. Kubernetes adds one ephemeral pod per session, which removes shared state and lets thousands of sessions run concurrently at cluster cost.
What are the trade-offs of running an agent in GitHub Actions?
Actions gives you isolated ephemeral jobs, a built-in secrets registry, and cron scheduling. You accept lock-in to a proprietary runner standard and you can only react to events GitHub emits, so Slack, Twilio and Datadog webhooks cannot start the agent.
Why is a dedicated VM a weaker isolation boundary?
Every agent on one VM shares the same file system and credentials, so a code review bot and an incident triage bot can reach each other's data and memory. The machine persists, which is useful for stateful workflows and risky when it drifts into a bad state.
Can an agent escape its sandbox?
Yes. Brennan cites an instance during Anthropic testing of the Mythos models where an agent broke out of its environment and gained internet access, and container escape attacks exist, including paths left open by outdated Docker versions. Sandboxing is a first pass at limiting reach, not a guarantee.
What does the principle of least privilege mean for a coding agent?
The agent should hold only the credentials and file access required for its job, typically one repository and a few secrets. It should not inherit the developer's environment variables, home directory secrets, or production cluster access.
How many agents can I run in each setup?
A laptop runs a handful of containers before performance suffers. GitHub Actions runs as many jobs as you pay for. A single VM shares one machine among all agents. Kubernetes can run thousands of pods, bounded by the CPU and memory you provision.
What starts an agent run in each environment?
Locally, a human types a prompt. GitHub Actions adds cron schedules and GitHub events. A long-lived VM adds HTTP webhooks from services such as Slack, Twilio and Datadog. Kubernetes supports cron jobs and HTTP events from Slack, GitHub and Jira.
What happens after sandboxing becomes normal?
Brennan expects more agents running in the cloud and in response to events, which leads to agents interacting with each other: one opens a pull request, another reviews it, and they go back and forth as multi-agent teams. The end state he describes is full SDLC automation where humans stop reading the source code.
If your video already explains this, publish it as an article
Every setup in this comparison started as an explanation someone worked through out loud: what least privilege means for an agent, why a shared VM breaks it, when a pod per session is worth the cluster work. If you have that kind of walkthrough sitting in a YouTube video, Skalablog turns the video into a written article you can edit and publish. Paste the URL, let it transcribe the talk, and generate the draft.
Fork this article
Start a new branch from the same video, shaped your way. You keep the credit; the original keeps the attribution.
A fork in another language is filed as a translation of this article, so the two pages point at each other. You can unlink it later from the editor.
0/240
You are creating
- Format
- For
- Language
- Source
- Your angle
You will be asked to sign in before it is generated.
Buy credits