OpenHands

The system is split across repositories. OpenHands/OpenHands holds Agent Canvas (the React client and the agent-canvas launcher); the Agent Server, agents and tools live in the Software Agent SDK; an Automation Server handles schedules and webhooks. Canvas only renders state and sends requests: the selected backend's Agent Server runs conversations, tools and workspace operations, and the workspace (host process, Docker, Kubernetes or a managed cloud sandbox) sets the isolation boundary.

Multi-agent work happens at two levels. Across conversations, Canvas can connect to several backends, give every conversation its own Docker container, and let an agent launch linked child conversations whose results flow back to the parent, which is supervisor-style delegation. Inside the OpenHands agent, the SDK's TaskToolSet delegates to named sub-agents (built-in or defined in Markdown files) that run synchronously and can be resumed later. A conversation can also run Claude Code, Codex or Gemini CLI instead of the OpenHands agent, through ACP.

Conversation state is persisted by the Agent Server so conversations can be resumed or branched from an earlier message; sub-agent conversations are saved to disk for resumption, and a condenser compresses long histories.

In the SDK, a conversation's confirmation policy decides when a person must approve actions: AlwaysConfirm, NeverConfirm or ConfirmRisky (paired with a security analyzer that rates action risk). When the agent is waiting for confirmation, the application can approve or call reject_pending_actions. File-based sub-agents can set permission_mode, otherwise they inherit the parent's policy. In Agent Canvas, approval and critic behaviour are configured under Settings > Verification, the composer shows the agent's current action, and a user can branch a conversation from any earlier message to try a different path.

npm install -g @openhands/agent-canvas

# prerequisites: Node.js 24+ and uv
npm install -g @openhands/agent-canvas

# full local stack (Canvas UI, Agent Server, Automation Server) on http://localhost:8000
agent-canvas

# or give every new conversation its own Docker container,
# so several agents can run at once without sharing a process
OH_CONVERSATION_RUNTIME=docker agent-canvas

# or run only the backend on an always-on machine and connect Canvas to it
agent-canvas --backend-only

# in the UI: choose OpenHands, Claude Code, Codex or Gemini CLI as the agent,
# add an LLM profile, then start a conversation

• Requires Node.js 24 or later and uv (the local agent server runs through uvx).
• The npm and source installs run the agent server directly on your machine with full filesystem access; use the Docker image or a VM for a sandbox, and read the self-hosting guide before exposing it.
• Local listeners bind to 127.0.0.1; with --host 0.0.0.0 the session key is no longer injected and you must enter an API key in the UI.
• Skills, MCP servers, secrets and other settings are saved per backend and do not carry over when you switch backends; MCP changes apply only to new conversations.
• ACP agents need their CLI installed and signed in (or an API key) on the backend machine, not on the browser's machine.

Yes. It connects to SSE, Streamable HTTP and stdio MCP servers and registers their tools with the agent. A2A and AG-UI support are not documented.

The code is MIT-licensed and can be self-hosted at no cost apart from model usage. OpenHands Cloud and OpenHands Enterprise are the project's commercial managed offerings.

Yes. Agent Canvas can run Claude Code, Codex or Gemini CLI as ACP agents; the backend launches the provider's CLI and reuses its login or an API key.

It is what the OpenHands/OpenHands repository now contains: a browser control center that connects to Agent Server backends where the agents actually run.

OpenHands focuses on coding agents and lets you run third-party coding CLIs through ACP; DeerFlow is a LangGraph-based research-and-creation harness from ByteDance with a lead agent that spawns sub-agents.