Rohit Malhotraandopenhands
e6d12e3fff
* spec(BM-001): add spec + failing tests for auto-switch on connect Adding a backend should automatically switch the active selection to it. Currently addBackend registers the entry but leaves the user on the previous backend, forcing a manual switch. - specs/backend-management.md: BM-001 definition - Two new test cases (cloud + local) that assert the active backend changes after addBackend — both fail against the current implementation. Co-authored-by: openhands <openhands@all-hands.dev> * fix(BM-001): auto-switch active backend on addBackend addBackend now calls setActiveSelection after registering the new entry, so the user lands on the backend they just connected — whether via the manual host+key form or the cloud OAuth device-flow login. - src/contexts/active-backend-context.tsx: one-line fix in addBackend - Updated add-backend-modal test to assert the new active selection - Updated backend-selector tests that used addBackend purely as setup to reset active to the default local backend afterward Co-authored-by: openhands <openhands@all-hands.dev> * chore: remove noisy @spec markers from test setup comments Keep @spec BM-001 only where it marks the implementation or directly asserts the spec behavior. Setup-only adjustments (resetting active backend after addBackend) are incidental — plain comments suffice. Co-authored-by: openhands <openhands@all-hands.dev> * chore: consolidate @spec BM-001 to one test + one implementation site The spec marker belongs in exactly two places: the line that implements the behavior and the single test that verifies it. Removed the redundant local-backend variant (same code path as cloud) and dropped @spec labels from the modal test (its assertion stays, just without the tag). Co-authored-by: openhands <openhands@all-hands.dev> * refactor: remove setActive workarounds from backend-selector tests Instead of manually resetting active state after addBackend, tests now work with the auto-switch naturally: - Local backend tests: click the seeded default 'Local' (which is no longer active after auto-switch) to trigger the switch. - Cloud org tests: add a local backend after the cloud one so the last auto-switch lands on local, leaving cloud backends unselected and their org rows visible in the dropdown. No ctx.setActive(DEFAULT_LOCAL_BACKEND_ID) calls remain. Co-authored-by: openhands <openhands@all-hands.dev> * refactor: extract shared seed constants in backend-selector tests SEED_LOCAL_1 and SEED_CLOUD_PRODUCTION replace 12+4 identical inline config objects. The two remaining inline blocks have different apiKey values and correctly stay as-is. Co-authored-by: openhands <openhands@all-hands.dev> --------- Co-authored-by: openhands <openhands@all-hands.dev>
agent-canvas
Warning
This project is in alpha phase. It may be vibecoded, untested, or out of date. Learn more.
OpenHands is a platform for orchestrating coding agents across different environments. You can:
- ⌨️ prompt agents manually
- 🕐 run agents on a schedule
- ⚡ trigger agents automatically — e.g. from Slack, GitHub, or Datadog.
Agents can run anywhere:
- 🧑💻 on your laptop
- 🖥️ on a remote virtual machine
- ☁️ in our hosted cloud
- 🏢 or inside your company’s infrastructure
The same Agent Canvas frontend can swap between each of these environments, so you can see everything in one place.
OpenHands works with any agent harness (e.g. Claude Code, Codex) or connect directly to an LLM (e.g. Anthropic, OpenAI, Gemini, Mistral, Minimax, Kimi).
If you have questions or feedback, please open a GitHub issue or join the #proj-agent-canvas channel in Slack
Quickstart
Direct Install
You can install OpenHands to run agents on any machine: on your laptop, on a dedicated computer like a Mac Mini, or on a server in the cloud.
The most powerful way to run OpenHands is on a server in the cloud. This allows your agents to continue running even when your laptop is shut, and makes it easier to trigger your agents through third-party services like Slack, GitHub, and Datadog. See SELF_HOSTING.md for details, especially with respect to security hardening.
Notably, you can run the backend in multiple different environments, and switch between them from the same Agent Canvas frontend. E.g. you can share an Agent Server with your team for agents doing code review and dependency updates, then have your personal agents running on your laptop.
Warning
This runs the agent-server directly on the machine you're installing on--the agent will have full access to your filesystem!
Prerequisites:
- Node.js 22.12.x or later
npmuv(for running the agent server viauvx)
git clone https://github.com/OpenHands/agent-canvas.git
cd agent-canvas
npm install
npm run dev
Access the UI at http://localhost:8000. You can add additional backends directly from the UI.
Architecture
Agent Canvas is powered by the OpenHands Agent Server, a REST API for running multiple agents on a single machine. Each Agent Server runs on a single host/port; the Agent Canvas can connect to multiple Agent Servers and easily flip between them.
You can run an Agent Server anywhere:
- Directly on your laptop (be careful!)
- On a dedicated machine like a Mac Mini
- On a virtual machine in the cloud
- Inside OpenHands Cloud (our commercial offering)
The Agent Server is often paired with an Automation Server, which lets you set up agents that run on a schedule or in response to events.
More documentation
For contributor and developer workflows, including frontend-only mode, mock mode, environment variables, and build/test commands, see DEVELOPMENT.md.