A control room, not just another coding agent
The repository still carries the OpenHands name, but its current README puts Agent Canvas in the foreground. Canvas is a web interface for starting agent conversations, inspecting files and commits, switching between backends, and creating jobs that run on a schedule or webhook. OpenHands is the included agent. Claude Code, Codex, Gemini, and other Agent Client Protocol implementations can sit behind the same interface.
That distinction matters. Aider and an editor assistant solve the immediate problem of changing code with a model. Agent Canvas tackles the operating problem that appears after a team has several agents, machines, and recurring tasks. One backend might review pull requests on a shared server while another works on private projects on a laptop. Canvas lets the user choose between them without changing the front end.
The project also supports automations that can react to GitHub events or publish results to services such as Slack. That makes it useful for dependency updates, issue breakdown, and recurring engineering reports. It also increases the cost of a mistake. An agent that can read repositories, call a model, and post to a team service holds meaningful access in several systems.
What happened when we ran it
We cloned commit 4bf8dd3 into a fresh Debian container with three CPUs, 8 GB of RAM, Node 22, no secrets, and no elevated privileges. The repository contained 2,119 files and about 278,843 lines of source in a 13.5 MB checkout. npm installed 1,998 packages in 50 seconds and occupied 1,043 MB on disk.
The build completed in 19 seconds. Tests also completed successfully, taking 454 seconds. That is a better source-build result than the size of the system suggests, especially because the repository has 19 CI workflow files and a dedicated tests directory. There was no Dockerfile in the checked-out source, even though the project publishes a ready-made container image for users.
npm audit found six known vulnerabilities: three high and three moderate. It reported no critical or low findings. The audit does not tell us whether each affected path is reachable in a normal Canvas deployment, so we will not turn that count into a breach claim. It is still a dependency result an operator should resolve or formally accept before placing the service near valuable source code.
The quick start has two very different risk profiles
The direct path is short: install the npm package and run agent-canvas, or clone the source, install dependencies, and start development mode. Node.js 22.12 or later is required, along with uv for launching the agent server through uvx. The README is unusually blunt about the consequence. A direct agent-server launch has full access to the machine's filesystem.
The Docker example is the better evaluation path. It mounts a chosen projects directory at /projects and keeps OpenHands state in a separate home directory. That boundary is only as good as the mounts and container permissions, but it is easier to inspect than giving an agent a developer's whole home directory. The UI then runs locally on port 8000.
Neither route produces useful agent work without a model connection. The settings support different providers and user-supplied models. Automations may also need GitHub, Slack, Linear, Notion, or other connector credentials. A remote Agent Server adds TLS, authentication, network policy, persistent state, backups, and secret rotation to the job. The README points self-hosters to a separate security guide, which should be treated as required reading rather than optional polish.
The architecture is honest about its boundaries
OpenHands is a multi-repository system. This repository owns Canvas, backend selection, and local orchestration. The Python software-agent SDK owns conversations, workspaces, tools, events, and the Agent Server API. A TypeScript client connects the browser to that API, while a separate automation repository handles schedules, webhooks, history, and dispatch.
This separation is sensible for maintainers, but contributors must find the correct home for a change. It also means a production diagnosis can cross several services. A missing conversation event after a VM restart is not the same class of problem as a Canvas rendering bug or a failed automation dispatch. Teams adopting the stack should log and monitor those layers separately.
The latest release, v1.15.0 on August 21, 2026, shows how wide the surface has become. It added provider connection controls, automation catalog installation, workspace paths, and conversation views, alongside fixes for streaming, sockets, remote URL parsing, and agent profile settings. This is active product work, not a repository receiving dependency bumps alone.
Where the beta label shows
Agent Canvas is explicitly marked beta. Current issue activity gives that label substance. Reports updated in August cover a conversation corrupted after a VM restart, a file preview that stops during streaming, a Windows local automation path error, and a stream setting ignored by the new-conversation form. Pull requests are moving alongside those reports, including work on event-file handling and late test requests.
The repository was pushed on August 27, 2026, six days after the latest release. GitHub showed 587 open issues and pull requests combined, not 534 confirmed defects. The queue is large, but same-day issue and pull-request movement plus 19 CI workflows point to an actively maintained project.
OpenHands makes the most sense for a team that already feels the friction of multiple agents and recurring jobs. For a single developer who wants help in one terminal, its control plane is extra machinery. For a team ready to isolate agent access and own the services around it, Canvas offers a coherent place to see what agents are doing and where they are running.