OpenHands: A Sandbox for Your Coding Agent, Not Your Laptop

Here's a question I kept dodging until it bit me: when your coding agent runs rm -rf, whose machine is it running on?

For most of last year, the honest answer for me was "my laptop." I'd point Claude Code or the OpenHands agent at a repo, tell it to fix a failing test, and walk away. It edits files, runs shell commands, installs packages, spins up a dev server. All of that on the same machine that holds my SSH keys, my logged-in browser sessions, and every other client project I've ever touched. That's a lot of trust to hand an autonomous loop that occasionally decides the fastest way to fix a test is to delete it.

OpenHands is the tool that made me stop doing that. It's a self-hosted control center for coding agents, and the interesting part isn't the chat window. It's where the code actually runs.

What OpenHands actually is

OpenHands started life as OpenDevin back in early 2024 and has since turned into something broader than "a coding agent." Today it's the place you run coding agents from. It'll drive its own built-in agent, but it also speaks to Claude Code, Codex, Gemini, and anything that talks the Agent Client Protocol (ACP). One interface, a VS Code editor, a terminal, a live app preview, and a chat panel, sitting in front of whichever model you feel like using that day.

You might be wondering why that matters if you already have a coding agent in your editor. The difference is the runtime. When an agent inside OpenHands runs a command, it doesn't run on your machine. It runs in a sandbox that OpenHands builds and controls. That single design choice is what the rest of this article is about.

How the sandbox actually works

Under the hood, OpenHands is a client-server system. There's a backend controller, a Python process that manages the agent loop and talks to your LLM, and there's the runtime, a Docker container the controller spawns for the task.

Here's the loop in plain terms. The agent looks at your task and decides on an action: run a shell command, read a file, apply a patch, click something in a browser. The backend doesn't execute that action itself. It ships it over a REST API to an "action execution server" running inside the container. That server has its own bash shell, its own browser instance, and plugin slots for things like Jupyter and VS Code. It runs the action, captures the result, and hands back an observation. The agent reads the observation, decides the next move, and the loop repeats until the job's done.

So the code the agent writes and runs lives inside the container the whole time. The container gives you the isolation you'd expect from Docker:

If you're extra cautious, there's an overlay mode. Set SANDBOX_VOLUME_OVERLAYS and append :overlay to a mount, and OpenHands gives the container a copy-on-write layer over your files. The agent sees the code and can work on it, but the original files on disk never get touched.

The part people get wrong

OpenHands V1 (late 2025 onward) gives you two workspace modes, and this is where I watched a teammate shoot themselves in the foot.

Local workspace is fast and frictionless, which is exactly why it's tempting. It also throws away the whole reason you'd run an agent this way, because now the agent is back to executing directly against your host. It's fine for a throwaway prototype on a machine you don't care about. It is not fine as your default. If you take one thing from this: run the Docker workspace unless you have a specific reason not to.

Why put it on its own server

Once you've accepted that the agent should run in a container, the next question is which host that container lives on. Your laptop still works, but now you're running Docker builds, dev servers, and an agent loop on the same battery-powered machine you're trying to actually work on. Put it on a dedicated box instead and a few things get better at once: the blast radius is a server you can wipe and rebuild, long tasks keep running when you close the lid, and your teammates can reach the same instance instead of everyone babysitting their own.

That's the case for self-hosting it on Elestio's managed OpenHands. It runs on a dedicated VM (one service per machine, fully isolated), starts at $16/month for the VM, and comes with automated backups, SSL, monitoring, and updates handled for you. You get the VS Code editor, terminal, and app preview in the browser, so the whole thing is reachable from anywhere without a local install. You still pay real infrastructure costs for the VM, but you're not hand-rolling Docker security on a box you also use for everything else.

Troubleshooting

The runtime container takes forever to start the first time. That's the image build. OpenHands uses a layered tag system (versioned, lock, and source tags) so it can skip work on later runs. The first build is the slow one; after that it reuses the cached layers and starts fast.

The agent says it can't reach the internet. You (or a default) probably locked down container networking. Loosen the network policy for that runtime if the task genuinely needs to fetch packages, and tighten it back for untrusted work.

Edits aren't showing up on my host. If you're on the Docker workspace with overlay mode on, that's working as designed. The copy-on-write layer keeps your host files untouched. Commit and push from inside the workspace, or turn overlay off if you actually want changes written straight to disk.

It's eating all my RAM. Set per-container CPU and memory limits. Agent loops that compile or run test suites can spike hard, and caps keep one runaway task from taking the host down with it.

The takeaway

Coding agents are only getting more autonomous, and "it runs on my laptop" ages worse every month. OpenHands gives you the same agents you already like, wrapped in a runtime that keeps their hands off the machine you actually work on. Put that runtime on its own server and you've got a setup you can hand to a whole team without losing sleep over what the agent might do at 2am.

Thanks for reading ❤️ See you in the next one 👋