OpenHands: The Open-Source Coding Agent, Explained

OpenHands is an open-source platform for AI coding agents that write code, run commands and work in a repository. You can use it four ways: Agent Canvas, a browser control center you run yourself; a terminal CLI; a Python SDK for building your own agents; or OpenHands Cloud, the hosted service. It is model-neutral, connecting to almost any model provider or a local model, and it can even drive Claude Code, Codex or Gemini CLI as the agent. Its main difference from a terminal agent like Claude Code is where the work runs: OpenHands is built around sandboxes, with Docker the recommended way to keep the agent away from the rest of your machine. It speaks MCP in every surface.

What it is, and who maintains it

The project describes itself as a community focused on AI-driven development, and its code lives in the OpenHands organization on GitHub. The main OpenHands repository↗ (opens in a new tab) now holds Agent Canvas and is MIT-licensed; the SDK, the automation server and the sandbox server live in their own repositories, and the docs say to check each one’s license rather than assume one license covers everything. OpenHands’ own default agent is called CodeActAgent.

A company sits behind it. The community page↗ (opens in a new tab) says OpenHands is supported by the for-profit All Hands AI, Inc., founded by three of the project’s first major contributors, and that the company may one day transfer custody of the project to an open-source foundation. All Hands runs OpenHands Cloud and sells OpenHands Enterprise; the open-source pieces are what you run yourself.

Four ways to run it

• Agent Canvas: the browser client and control center for conversations, files, terminals, model settings and automations. The agent-canvas launcher starts the client and its backend services on your machine, installed with npm or npx (it needs Node.js 24 or later and uv), or as one Docker container. You can also point the client at a backend on a VM, in Kubernetes, on Modal, or in OpenHands Cloud.
• CLI: a terminal agent built on the SDK, installed with uv tool install openhands --python 3.12 or an install script, and started with openhands. The docs call it feature-complete and maintained mainly for stability. On Windows it runs inside WSL.
• Software Agent SDK: a Python library for building agents, plus Agent Server, which exposes conversations, tools and workspaces over REST and WebSocket APIs.
• OpenHands Cloud: the hosted service. You sign in with GitHub, GitLab or Bitbucket, and it adds integrations such as Slack and Jira Cloud, organizations and budgets.

Older guides describe a Docker-based Local GUI started with openhands serve. The docs now call that the legacy Local GUI, deprecated in favor of Agent Canvas, so follow current instructions if a tutorial’s commands do not match what you see.

# needs Python 3.12+ and uv; on Windows, run inside WSL
uv tool install openhands --python 3.12
openhands                  # first run asks for your LLM settings

# or start with a task
openhands -t "Add input validation to the signup form and run the tests"

Models and providers

OpenHands brings no model of its own. Its LLM overview↗ (opens in a new tab) says it can connect to any model LiteLLM supports, but that it needs a powerful model to work well. There are four routes in:

• A provider API key: Anthropic, OpenAI, Google, Azure, Amazon Bedrock, Groq, OpenRouter and the rest of LiteLLM’s list.
• An OpenHands LLM key, for hosted models the project has verified.
• An ACP agent: Agent Canvas can run Claude Code, Codex or Gemini CLI through the Agent Client Protocol, reusing that tool’s own login when the backend runs on the same machine.
• A local model through Ollama, LM Studio, vLLM or SGLang, or any OpenAI-compatible gateway.

The same page warns that open-weight and local models vary widely in how reliably they call tools, and that OpenHands sends many prompts to the model, so set spending limits with your provider. The project publishes its own OpenHands Index of model results if you want a starting point.

The sandbox

A sandbox is where OpenHands runs commands, edits files and starts servers. The sandbox overview↗ (opens in a new tab) lists three providers: Docker, recommended, which runs the agent server in a container with good isolation from your host; Process, which runs it as an ordinary process with no container isolation and which the docs label unsafe but fast; and Remote, used by hosted setups.

The install method decides the boundary. A local npm install of Agent Canvas runs the agent with your user account’s permissions, and the docs are blunt that Agent Canvas is only the client and provides no isolation. The Docker image sees only the folders you mount, typically a projects folder, and by default the agent inside cannot start containers of its own; letting it do so means running with --privileged, which widens what it can reach. In the CLI, the default is to ask before each action, --always-approve skips the questions, and --llm-approve hands the decision to an LLM-based security analyzer. Headless mode, openhands --headless, is meant for scripts and CI and always runs as if --always-approve were set, so give it a sandbox you are willing to lose.

MCP support

OpenHands is an MCP client in every surface. According to its MCP page↗ (opens in a new tab), it reads your MCP configuration at startup, connects to each server over SSE, Streamable HTTP or stdio, and registers their tools with the agent. The CLI keeps servers in ~/.openhands/mcp.json and manages them with openhands mcp add, list, enable and disable, with OAuth or custom headers for remote servers; /mcp shows their status inside a session. Agent Canvas and OpenHands Cloud configure servers in settings, and the SDK does it in code.

For standing instructions, OpenHands reads an AGENTS.md at the repository root as always-loaded context, and adds skills: keyword-triggered instructions, organization-wide skills, and path-triggered rules that load whenever the agent touches matching files. Plugins bundle skills, hooks, MCP servers and commands into one package.

openhands mcp add fenbs --transport http --auth oauth https://fenbs.ai/api/mcp
openhands mcp list

OpenHands and Claude Code, briefly

• Where it runs: OpenHands is built around a backend and a sandbox, local, on a VM or in the cloud, with a browser client on top. Claude Code runs in your terminal, IDE, desktop app or Anthropic’s cloud.
• Models: OpenHands runs almost any model, or another agent through ACP. Claude Code runs Claude models.
• Isolation: Docker is OpenHands’ recommended default. Claude Code relies on permission modes and an optional sandbox for commands.
• Openness: the main OpenHands repository is MIT-licensed and community-run with company backing. Claude Code is distributed under Anthropic’s terms.
• Automation: both run headless in CI. OpenHands adds scheduled and event-driven automations in Agent Canvas; Claude Code has claude -p, hooks and a GitHub integration.

OpenHands suits teams that want model freedom, want agents contained in Docker by default, or want one browser view over several agents including Claude Code. Claude Code suits developers who want Anthropic’s agent close to their editor with the least setup. For the rest of the field, see Claude Code alternatives and the best AI coding agents.

Giving OpenHands a task board

An OpenHands conversation belongs to one backend and ends with its own history, which is a poor place to keep a team’s list of work. fenbs is a board where AI assistants are members. Add https://fenbs.ai/api/mcp as a remote server and sign in with OAuth, or issue a token under Settings with a name, scopes and an optional expiry and pass it as a header. OpenHands can then read the next task, including its note and plan, move it through To Do, Next Up, In Progress and Completed, record a test status, and comment with what it changed. History records each change under the assistant’s name, and revoking the token ends its access. fenbs has no sprints, due dates or epics; it keeps the work and who did it in one place.