OpenHands
Short answer: if you want a coding agent that cannot touch your host filesystem unless you let it, OpenHands is the mainstream option — but as of 2026-07-31 the sandbox is not what you get by default any more. The container isolation is real, well documented, and still the reason to choose this over a terminal agent. It is now one install path among several, and the quickest one runs the agent directly on your machine.
That is the most important thing to know about OpenHands today, because most of what is written about it says the opposite. This page is what we verified on 2026-07-31, install commands included.
On this page
What it is, and the name it used to have
OpenHands is an open-source platform for software engineering agents, MIT-licensed except for the enterprise/ directory. Reading the GitHub API on 2026-07-31, the repository showed 82,633 stars and 10,619 forks, with 287 open issues, and it has been going since March 2024.
It launched as OpenDevin, an open answer to the then-closed Devin. The rename is documented by the project itself: the abstract of its ICLR 2025 paper opens "OpenHands (f.k.a. OpenDevin)". If you find a guide that talks about OpenDevin, it is about this software and it is at least two years stale.
The founding idea has not changed. The agent does not only write code — it runs commands, starts servers and browses the web, the way a developer would. Everything else follows from the question that raises: where should all that run?
The sandbox, and what changed in V1
OpenHands calls the execution environment a sandbox. Older docs called it a runtime, and the configuration knob is still named RUNTIME while the migration finishes. There are three providers, described in the docs like this:
Docker sandbox (recommended) — Runs the agent server inside a Docker container. Good isolation from your host machine.
Process sandbox (unsafe, but fast) — Runs the agent server as a regular process on your machine. No container isolation.
Remote sandbox — Runs the agent server in a remote environment.
The candour of "unsafe, but fast" is characteristic and welcome. On that page RUNTIME=docker is still the stated default, and the Docker sandbox page still calls itself "the default and recommended option for most users".
But the front door moved. The current flagship surface is Agent Canvas, a browser UI plus backend server, and its install page ranks options by convenience rather than isolation. Its own trust-boundary table reads:
| Setup | Trust boundary, in the docs' words |
|---|---|
| npm local install | "Runs directly on your machine. The agent server can operate on the local filesystem." |
| Docker | "Runs inside a container and only sees the directories you mount." |
| VM or dedicated machine | "Runs on the remote host you control." |
| OpenHands Cloud | "Runs in managed OpenHands Cloud sandboxes." |
And the guidance beneath it: "If you are new to Agent Canvas, use npx for a quick first run or npm local install if you want a reusable agent-canvas command. Use Docker when you specifically want sandboxing."
What you buy with the container is a structural answer to a question most agents answer with a dialog box. An approval prompt is a decision you make dozens of times an hour, about commands you have not fully read. A mount boundary is a decision you make once. The cost is that the container is also where the failures live: Docker has to be running, the image has to pull, and the agent only sees what you mounted — the source of most "it edited the wrong files" confusion.
Four things share the name
Search results conflate these constantly. As the docs organise them on 2026-07-31:
| Surface | What it is | Status |
|---|---|---|
| Agent Canvas | Browser UI plus a backend agent server, with automations. One agent-canvas command starts the stack. | Current flagship |
| Software Agent SDK | A composable Python library — "the engine that powers everything else". Define agents in code and "scale to 1000s of agents in the cloud". | Current, separate repo |
| OpenHands Cloud | Managed hosting with GitHub/GitLab/Bitbucket, Slack, Jira and Linear integrations, RBAC and budget enforcement. | Commercial |
| OpenHands CLI and Local GUI | The terminal agent, and the original Docker-based web app. | Filed under Legacy in the docs |
That last row deserves care rather than alarm. "Legacy" here means "not what we point new users at" — the CLI still carries a full, current documentation section. But it signals where effort is going, and the two stacks do not share an entry point: openhands serve, the docs note, "starts the legacy OpenHands CLI GUI server and will not run if you have only installed agent-canvas".
Installing it
All commands below are from the official docs read on 2026-07-31. Versions here move weekly; check the pages linked at the end before pasting.
Agent Canvas, sandboxed (the one you probably want)
Requires Docker running.
mkdir -p ~/projects ~/.openhands
docker run -it --rm \
-p 8000:8000 \
-v ~/.openhands:/home/openhands/.openhands \
-v ~/projects:/projects \
ghcr.io/openhands/agent-canvas:latest
Then open http://localhost:8000. The agent reaches project files under the mounted /projects directory and nothing else on your machine.
Agent Canvas, on your host
Needs Node.js 22.12 or later and uv — the local agent server runtime uses uvx, and a missing uv is one of the most common startup failures.
npm install -g @openhands/agent-canvas
agent-canvas
Or without installing globally:
npx @openhands/agent-canvas
The CLI
Python 3.12+ with uv, which is the documented recommendation:
uv tool install openhands --python 3.12
openhands
Or a prebuilt binary:
curl -fsSL https://install.openhands.dev/install.sh | sh
On Windows the CLI is WSL-only; native Windows is not officially supported. To give the CLI's sandbox access to the repository you are standing in:
openhands serve --mount-cwd
or set the mount explicitly, in host_path:container_path[:mode] form:
export SANDBOX_VOLUMES=$PWD:/workspace:rw
Browser, terminal, headless
The CLI exposes five modes from one binary, which is more range than the browser-first framing suggests:
| Command | What you get |
|---|---|
openhands | Interactive terminal |
openhands --headless -t "…" | No UI — scripts, CI |
openhands web | Browser-based terminal |
openhands serve | The full web GUI |
openhands acp | Zed, VS Code, JetBrains over the Agent Client Protocol |
Headless mode takes --json and streams JSONL events, one object per action and observation, which makes it genuinely scriptable rather than merely non-interactive.
always-approve mode. The agent will execute all actions without any confirmation. This cannot be changed." Combined with the process sandbox, that is an agent with no gate at all. In a pipeline, the container is not optional — it is the entire safety model.Models, and running someone else's agent
OpenHands is bring-your-own-key by construction, with four documented paths: a direct provider key (Anthropic, OpenAI, Google and others), an OpenHands LLM key for their hosted routing, a local OpenAI-compatible server such as Ollama, LM Studio, vLLM or SGLang, or a LiteLLM proxy via the litellm_proxy/ prefix.
The more interesting option is that OpenHands will run a different vendor's agent inside its own sandbox. Over the Agent Client Protocol it spawns Claude Code, Codex or Gemini CLI as a subprocess and relays each turn to it — the external agent brings its own model and tools, and OpenHands supplies the UI, the workspace and the container. If your objection to terminal agents is where they execute rather than how well they reason, that is the specific combination to try.
~/.codex/auth.json for Codex. A backend in Docker, on a VM or in the cloud cannot see the login on your laptop, so it needs a key instead. The same principle catches local models: the docs warn that "a backend in Docker cannot use 127.0.0.1 to reach a model server running on the host."Where it's rough
Three honest weaknesses, all observable today rather than inferred.
Startup is where the bug reports cluster. The published troubleshooting page is almost entirely about getting the thing to boot: agent-canvas not on PATH, missing uv or uvx, port 8000 already taken, the Docker daemon not running, the browser loading but the backend unreachable. The issue tracker matches. All three of these were open on 2026-07-31: a Windows launcher that shell-parses uvx version constraints and prevents the agent server starting, a server-info check that never completes from the Windows installer, and conversation creation returning 500 on Fedora with Python 3.14. None of these are exotic environments. Budget an afternoon for the first install.
The version surface is large and the docs lag it in places. The repository shipped v1.6.1, v1.7.0, v1.7.1, v1.7.2 and v1.8.0 between 2026-07-28 and 2026-07-30 — five releases in three days. The SDK versions independently (v1.39.1 on 2026-07-30), and the documented Docker commands pin an agent-server image tag by hand. Treat any version string you copy, including from this page, as something to check.
The reorganisation is not finished. Sandbox providers are selected through a variable still named RUNTIME. The CLI is labelled legacy while carrying live documentation. Two install stacks overlap with different entry points. Nothing here is broken, but the docs, blog posts and search results are describing at least two products under one name, and you have to track which one you are reading.
For scale, one outside measure: on OpenRouter's coding leaderboard, read on 2026-07-31, OpenHands sat thirteenth at 15B tokens for that day, behind Codex and just ahead of Cursor, with the leaders — Hermes Agent at 970B, Claude Code at 422B — an order of magnitude clear. That board counts only applications that opt into tracking, and only traffic routed through OpenRouter, so it is not market share. It does indicate a real working user base rather than a hobby project, and not one of the giants.
Where it fits next to a terminal agent
Claude Code, Codex and the other terminal agents are a different shape, not a lesser one. They run in your working directory with your credentials already loaded, and the boundary between you and a bad command is an approval prompt plus whatever policy you configure — Claude Code can block a tool call deterministically with hooks. That shape is faster, has no container to start, and fits an existing repo with no setup.
Pick OpenHands when the isolation is the point:
- You are running agents against code you do not trust — a dependency audit, an unfamiliar repository, anything where the code being read is itself a threat surface.
- You want an agent working while you do something else on the same machine. A container keeps its mess in one place.
- You want a browser UI rather than a terminal, without a separate hosted product.
- You want automations on infrastructure you own — scheduled runs, PR review, repository monitors — or need the agent on a VM, Modal or Kubernetes with the same UI in front.
Skip it if your workflow is a single trusted repository and a terminal you already live in. The setup friction and startup time are real, they are the recurring complaint, and they buy a property you may not need. If you do need it, nothing else in the mainstream offers the same thing with this much documentation behind it. Our Cursor vs Claude Code page covers the other half of the decision.
Where we fit, briefly
We build UFO, so weigh this accordingly — and it changes nothing above. If the question is "which coding agent should I run, and should it run in a container," the answer is on this page and it is not us.
UFO is the layer after that one: a team chat where AI agents are members of channels alongside people, each running on a machine you have paired, with task cards for work that outlives a session and human-only channels the agents cannot see. OpenHands is a thing you could run on one of those machines.
It matters once there are several agents, on several models, and other people need to see what they did — a different question from the one this page answers.
Sources
Every command, quotation and figure here comes from OpenHands' own documentation, repository and issue tracker, read on 2026-07-31 against v1.8.0. Where the sandbox docs and the current install paths disagree about what is isolated by default, this page says so rather than picking one. We found no product called a "Large Codebase SDK" anywhere in the OpenHands organisation or docs on that date, so it is not described here.
- github.com/OpenHands/OpenHands · v1.8.0 release · software-agent-sdk · OpenHands-CLI
- Sandboxes — overview · Docker sandbox · Custom sandbox images
- Agent Canvas overview · install · troubleshooting · ACP agents · LLM profiles
- CLI installation · CLI quick start · headless mode · legacy local setup
- arXiv:2407.16741 — the paper whose abstract records the OpenDevin rename
- openrouter.ai/apps/category/coding — the leaderboard snapshot quoted above
Not affiliated with the OpenHands project. If something here is wrong or has gone stale, tell us and we'll fix it.