The documented OpenHands/OpenHands architecture makes a useful refusal: its Agent Canvas does not execute the agent’s actions or provide the sandbox and workspace isolation layer. It selects and speaks to Agent Servers, which can run locally, remotely, or in the cloud.
That distinction becomes consequential when a control surface must choose a backend after one fails. The canvas is a selector, not a promise that the machine acting is the one a person intended to use.
That is what the newest backend-registry commit handles. With no valid explicit selection, the frontend now prefers a healthy local backend over a cloud entry that happens to appear first, and over a local entry already marked unhealthy. Its tests cover a cloud-first list, a failed local server followed by a healthy one, and the exception that matters: an explicit cloud selection remains the operator’s.
This is not a glamorous capability. It is the condition for a dashboard to remain a control surface instead of becoming a confusing map of unavailable machinery.
The canvas is not the agent
The project partitions responsibilities often blurred into the word “agent.” The canvas renders conversation, terminal, browser, files, settings, and automation controls. The Agent Server owns the execution interface; an ingress and automation service are optional runtime neighbors.
The documented Docker mode is the safer local path. The documented host-mode path can give an agent access to the filesystem, environment, and network, and the project’s self-hosting guide makes the consequence direct: someone who can reach an exposed Agent Server may be able to do what the agent can do.
That makes the fallback more than UI housekeeping. A person who means to use a local, bounded setup should not silently lose that execution path because a cloud entry came first in a registry or because one local process went bad.
Conversely, the code does not override an explicit cloud choice. It protects the difference between recovery assistance and a covert policy decision.
What the fresh patch does—and does not—settle
The commit comment explains the target: a cloud or dead-local backend at the top of a list could leave the local resolver empty even when a healthy Agent Server sat farther down. The new rule consults persisted health, falls back to another local backend, and only then returns to the prior first-entry behavior.
The source and tests do not prove that a deployment is secure, that a Docker boundary is configured correctly, or that every ACP-compatible agent behaves alike once connected. Those remain operator and runtime questions.
But the patch offers a durable rule for anyone building an agent control surface: keep execution choice explicit, keep failure state visible, and make recovery respect the person’s stated choice. The next decisive public signal would be an end-to-end failover test across local, cloud, and unavailable backends that preserves both that choice and the workspace boundary.