OpenHands: the open-source coding agent you operate

OpenHands is an MIT-licensed platform for running coding agents: a web front end called Agent Canvas, a CLI, a headless mode, a Python SDK and a REST API, all driving agents that edit files and run commands inside a sandbox. The position of this review: it is the most complete open-source option for teams that want to own the execution environment, and it behaves like a platform under active construction rather than a finished product.

It sits where Claude Code, Codex CLI, Aider and the hosted agents sit, between the model and the repository, but on a different contract: the model is a pluggable dependency instead of a bundled one, and the runtime is your infrastructure instead of a vendor’s. Version 1.25.0 was released on 6 October 2026.

What it is

OpenHands began as a single repository and is now four: the Agent Canvas front end and local orchestration in OpenHands/OpenHands, the Python agent server and SDK in software-agent-sdk, a TypeScript client, and a separate automation service. That split is the first thing to understand before adopting it.

• MIT licence, with the hosted service sold separately by All Hands AI.
• Version 1.25.0, released 6 October 2026, pinning the agent server and the SDK to 1.53.0.
• Surfaces: the Agent Canvas web UI, an interactive CLI, headless mode for CI, a Python SDK, and a REST API for conversations, events and sandboxes.
• Model agnostic through LiteLLM, with profiles for switching models inside a conversation and local servers such as Ollama and vLLM supported.
• Sandbox providers: Docker as the recommended option, a process mode without container isolation, and remote sandboxes for hosted setups.
• Agent Client Protocol support lets Canvas drive Claude Code, Codex or Gemini CLI as alternative backends.
• Automations run on schedules, GitHub events or webhooks, with prebuilt templates for issue to pull request and pull-request review.

Underneath, the agent server exposes a workspace, a tool set covering bash, file edits, a browser and an interactive terminal, plus skills, hooks and MCP servers. The canvas and the automation service are clients of that API, which is why one conversation can start from a button, a cron job or a webhook.

How it works

A conversation is a stream of typed events: the agent proposes an action, the action runs in the sandbox, the observation comes back, and the loop continues until the model stops. The interesting decisions sit at the boundary — which files the workspace exposes, which commands the policy allows, and which model profile pays for the next turn.

Because the loop lives in the agent server rather than in the UI, the same conversation can be started from the canvas, the CLI, a schedule or a webhook, and can be paused, resumed, branched or exported as a trajectory. That is the architectural argument for the project: one execution path with several entry points.

Getting started

The documented route is Docker: one container publishes the canvas on localhost, mounts a projects directory the agent may reach, and keeps its state in a home directory volume.

# one container for the canvas, the agent server and a mounted workspace
export PROJECTS_PATH="$HOME/projects"
mkdir -p "$PROJECTS_PATH" "$HOME/.openhands"

docker run -it --rm \
  -p 127.0.0.1:8000:8000 \
  -e AGENT_CANVAS_ALLOW_LAN_SESSION_KEY=true \
  -v "$HOME/.openhands:/home/openhands/.openhands" \
  -v "${PROJECTS_PATH}:/projects" \
  ghcr.io/openhands/agent-canvas:1.25.0

# open http://localhost:8000, add a model key, start a conversation

The npm route, npm install -g @openhands/agent-canvas, needs Node.js 24 and uv and runs the agent server directly on the host; the README warns that this gives the agent full access to the filesystem. The container route is the one to copy into a team setup.

Sandboxing and blast radius

The sandbox is the security boundary, and the docs are blunt about the options: Docker is recommended, process mode is labelled unsafe but fast, and remote sandboxes serve hosted deployments. A sandbox is where commands run and files get edited, so its configuration decides what a prompt can do to a machine.

• The Docker sandbox runs the agent server in a container and is the recommended provider on a workstation.
• The process sandbox runs it as a normal process with no container isolation: faster, and only for trusted work.
• OH_CONVERSATION_RUNTIME=docker gives every conversation its own container, with its own workspace and state.
• Hooks can block dangerous commands and enforce checks before the agent stops, and a confirmation policy can require approval for actions.
• Workspaces are limited to a mounted projects path, so the default container cannot see the rest of the host filesystem.

Automations

Automations are the reason to pick this over a terminal agent. A task runs on a schedule or on an event — a GitHub issue, a pull request, a webhook — dispatches a conversation to an agent server, and the result comes back as a comment, a pull request or a Slack message.

• Prebuilt templates cover issue to pull request, pull-request review, repository monitoring and a Slack channel monitor.
• Schedules and event triggers share one dashboard, with run history and enable or disable per automation.
• Automations can be exported, imported and synced with a Git repository, so they are edited as files and shared like code.
• Integrations cover Slack, GitHub, Linear, Notion and webhooks; the automation service runs as its own repository and process.
• With a container per conversation, parallel automations do not fight over one workspace.

This is also where the operational cost appears: an always-on canvas, an automation service and per-conversation containers are three more things to watch than a terminal agent. The project’s own use-case pages describe a four-automation pipeline from issue to merge, which is a fair target and an honest amount of machinery.

Where it shingles

The weaknesses first: OpenHands moves fast and its surface shows it. Terminology changed from runtimes to sandboxes in V1 while configuration still reads RUNTIME, the front end is now Agent Canvas rather than the older web UI, and the code is spread across four repositories with separately versioned pieces. Teams that pin nothing will find upgrade notes in their tickets.

• API stability: the SDK and the agent server version independently of the canvas, and the 1.25.0 notes pin them to 1.53.0.
• Outcome quality tracks the model: the project’s own OpenHands Index finds small gaps between models on issue resolution and much larger ones across its five-task mix.
• Self-hosted automations need a machine that is always on, plus credential management for GitHub, Slack and the model provider.
• The GUI, the CLI and the canvas overlap, so a team has to choose an entry point instead of inheriting one.

Most of that is managed with discipline rather than avoided: pin the three version numbers together, keep one entry point per team, and read a release note before it reads as an incident.

The comparison is really about infrastructure. OpenHands buys sandboxed, schedulable, model-agnostic execution and charges for it in always-on services; the terminal agents buy simplicity and give up the control plane.

Verdict

Adopt OpenHands when the work is unattended: issues that should become pull requests, reviews that should run on every merge, monitors that should watch a repository. For interactive work in one repository, a terminal agent plus a sandbox you already trust is less machinery for the same result.

1. Use it when the model has to stay a swappable dependency: profiles, LiteLLM providers and local servers are first class, so no single vendor is load-bearing.
2. Use it self-hosted when owning the execution environment is the point; the MIT licence and the Docker path make that a supported route rather than a workaround.
3. Start with the container install, keep projects mounted from one directory, and treat process mode as a debugging convenience.
4. Do not adopt it for a stable API: pin the canvas, the agent server and the SDK together and read each release note before upgrading.
5. Do not enable automations you cannot audit: every schedule is an agent holding credentials, so confirmation policies and hooks belong on by default.

OpenHands is not a tool you run on a project. It is a small platform that runs your agents, and the platform is the part you have to staff.

Sources

1. OpenHands README
2. OpenHands licence (MIT)
3. Agent Canvas 1.25.0 release notes
4. OpenHands sandbox overview
5. OpenHands quick start
6. OpenHands pricing
7. Introducing the OpenHands Index