OpenHands Agent Canvas: Orchestrating Claude Code, Codex and Gemini on a Self-Hosted Platform

From a single coding agent to an agent team coordination center

Vibe Coding is entering a new phase. The question is no longer just which model writes better code, or which extension completes a prompt faster. When developers start assigning AI tasks that last tens of minutes, run simultaneously across multiple repositories, receive events from GitHub or Slack, and continue working when the laptop is off, the biggest challenge shifts from "code generation" to "system orchestration."

OpenHands Agent Canvas is built precisely for that gap. Instead of competing as a model or a new chat window, Agent Canvas positions itself as a developer control center: a unified interface to run OpenHands Agent, Claude Code, OpenAI Codex, Gemini CLI, or any agent compatible with the Agent Client Protocol. Agents can run locally on a laptop, in Docker, on a VM, on enterprise infrastructure, or on OpenHands Cloud; users switch backends within the same interface instead of switching tools.

The key point to understand is that OpenHands and Agent Canvas are not entirely synonymous. The main repository OpenHands/OpenHands currently has about 82,000 stars and over 10,000 forks, reflecting the community scale of the entire project. The Agent Canvas interface source code is being split into the OpenHands/agent-canvas repository, released under the MIT License but still labeled Beta. At the time of checking, this separate repository has over 100 stars, over 800 commits, and the number of issues and pull requests is still changing rapidly. The 82,000 stars of the main project should not be used to claim that Agent Canvas alone has matured to the level of a long-standing stable product.

The repository split also reflects the new architecture. The OpenHands Software Agent SDK and Agent Server become the Python foundation layer; Agent Canvas is the frontend and control surface primarily written in TypeScript; the Automation Server manages scheduled or event-driven tasks. This is a notable direction: a coding agent ecosystem no longer revolves around a single LLM loop, but is divided into agent harness, execution environment, orchestration layer, integration, and observability.

What problem does Agent Canvas solve?

A coding agent running in a terminal or IDE is typically optimized for one developer and one session. The user opens a repository, enters a task, watches the agent edit files, run tests, then review diffs. This model is very effective for direct interactive work, but begins to show limitations when you need to:

• Run multiple agents in parallel without them overwriting the same working tree.
• Continue tasks on a server when the laptop is off.
• Use Claude Code for one repository, Codex for another, and OpenHands Agent for automated workflows.
• Trigger agents from issues, pull requests, webhooks, Slack, or scheduled calendars.
• Keep history, output, status, and access rights in one place.
• Turn a process into reusable automation instead of manual prompting.
• Manage secrets, MCP servers, skills, and model profiles for multiple jobs.
• Separate the control interface from where the agent actually runs.

Agent Canvas focuses on that orchestration layer. According to the official product page, the platform supports multiple agents running in parallel, each agent can be isolated using Git worktrees; scheduled or event-driven automation; local, VM, and cloud backends; a library of skills, MCP connections, and agent harnesses via ACP.

This does not make Agent Canvas a model. The quality of reasoning, code, and tool use still depends on the agent harness, model, context, configuration, and project tests. Canvas is where users choose, observe, and connect those components into a working system.

Architecture: Canvas, Agent Server, workspace, and automation

Agent Canvas is the interface and orchestration layer

Agent Canvas provides an interface to create conversations, select backends, connect agents, view history, configure skills, MCP, and automations. The frontend does not have to run on the same machine as the agent. A Canvas on a laptop can connect to an Agent Server on a VM; a team can use a shared server for dependency updates and code review, while individual agents still run locally.

Agent Server is the execution layer

OpenHands Agent Server is an HTTP/WebSocket service for running agents remotely. The server manages conversations, workspaces, files, commands, and streams events to the client. The same API SDK can be used with local workspaces, Docker workspaces, or remote workspaces, allowing applications to change execution environments without rewriting the entire agent logic.

In the new SDK architecture, the agent server is a separate Python package. It can run directly, in a container, on a VM, or on Kubernetes. The workspace layer is responsible for where the agent reads files, executes commands, and creates artifacts; the client only controls the conversation and receives events.

Automation Server turns conversations into repeatable processes

Automation is not just scheduled prompting. According to the OpenHands Automations documentation, each run creates a full conversation in a new sandbox, which can use configured LLM profiles, stored secrets, Git credentials, and MCP integrations. Results are saved for users to review or continue the conversation.

Typical workflows include issue summarization, dependency checking, security scanning, report generation, data synchronization, and notification sending. This is the difference between a control center and a chat client: work is defined once, triggered by schedule or event, creates logs for tracking, and can scale across multiple repositories.

ACP decouples the interface from the agent harness

The Agent Client Protocol uses JSON-RPC to standardize communication between client and agent. OpenHands can act as a client controlling another ACP agent, or provide an agent via ACP to an IDE. In Agent Canvas, ACP is the bridge to use Claude Code, Codex, Gemini CLI, and other compatible harnesses without forcing developers to abandon familiar subscriptions, models, or workflows.

The value of the protocol layer is reducing dependency on a single agent. If a team uses Claude Code for long refactors, Codex for cloud-based tasks, and OpenHands Agent for automation, Canvas can become the common management layer. However, "supporting the same protocol" does not mean every feature of each agent will be identical. Approval, tools, resume, authentication, and billing still depend on the underlying harness.

Parallel agents and Git worktrees: big benefits, but not a conflict solver

Agent Canvas advertises the ability to run multiple agents in parallel, each in its own Git worktree. This is a reasonable way to isolate the filesystem: each task has its own working directory and branch, preventing two agents from modifying the same physical file in one checkout.

Worktrees do not eliminate logical conflicts. Two agents could modify the same module in different ways, change schemas incompatibly, or both update a dependency. When merging, a human or a verification workflow must still evaluate ordering, integration tests, and cross-branch impacts. Parallelism increases throughput; it does not turn a repository into a self-merging system.

A practical strategy is to divide tasks by clear boundaries: one agent handles tests, one updates documentation, one investigates bugs; or split by packages with minimal dependencies. For cross-module migrations, a planning agent should lock architectural decisions before running multiple execution agents.

Which models and agents does Agent Canvas support?

The default OpenHands Agent allows configuring multiple LLM providers and API endpoints. Agent Canvas also supports third-party agents via ACP. The product page currently lists Claude Code, Codex, Gemini CLI, and OpenHands Agent. This creates two usage models:

• Bring your own model: run OpenHands Agent and provide API keys for Anthropic, OpenAI, Google, Mistral, MiniMax, Kimi, or a compatible endpoint.
• Bring your own agent: connect Claude Code, Codex, Gemini CLI, or another ACP agent, keeping that harness's subscription and behavior.

The two models have different cost structures. With an API key, users pay per token or request and control model profiles themselves. With agent subscriptions, limits may be based on plans, quotas, or provider policies. Agent Canvas does not make model costs disappear; it consolidates agents onto one control surface.

Enterprises should record the actual model used per run, duration, tool calls, retry count, and review time. A more expensive agent per token may be cheaper if it completes tasks in fewer attempts. Conversely, running many agents in parallel without setting a budget can lead to unpredictable bills.

Automation and integrations: from GitHub issues to Slack reports

Agent Canvas aims for automation via schedule, webhook, polling, and events. One workflow could receive a GitHub issue, analyze its scope, create tasks, run an agent in a worktree, open a pull request, and send a summary to Slack. Another workflow might check dependencies weekly, monitor API health, aggregate incidents, or generate release reports.

Integrations are provided through Git credentials, MCP servers, plugins, and skills. The Automations documentation notes that the Git provider used for login can be automatically injected into the conversation; services like Slack require MCP integration or appropriate secrets. This is convenient but expands the agent's permission scope.

Do not grant a full-access GitHub token to a workflow that only needs to read issues. For Slack, the bot should only be added to necessary channels. For Notion, Linear, or internal systems, tokens should use minimal scopes and be separated by environment. Automation running without direct human oversight must have stricter limits than interactive conversations.

Installing Agent Canvas locally

The repository currently requires Node.js 22.12 or higher and uv. The quickest way is to install the npm global package:

npm install -g @openhands/agent-canvas
agent-canvas

The agent-canvas command starts the full local stack. To separate components, users can run:

agent-canvas --frontend-only
agent-canvas --backend-only

The interface opens by default at http://localhost:8000. Then users can add backends, connect agents, configure LLMs or subscriptions, and create conversations.

An important warning in the README: direct installation causes the agent server to run on the machine with full access to the filesystem that the current user can access. This is an easy-to-install and easy-to-debug choice, not a secure default configuration for repositories containing secrets, SSH keys, personal documents, or production credentials.