OpenClaw merged a Cloud Worker Desktop hardening pass in PR #126417, tightening the provider contract for Crabbox-backed Browser and Terminal workers.
The problem was a setup boundary, not a flashy UI bug. Desktop-enabled worker profiles could start unsupported Crabbox providers, depend on an implicit desktop environment, or execute provider-owned environment files as shell input during Browser and Terminal setup.
That is risky in two ways. Unsupported providers should fail before allocation, not after a lease has already been created. And provider-generated environment files should communicate fixed environment facts, not gain shell authority during launcher setup.
What Changed
The follow-up makes the supported route matrix explicit before worker allocation. AWS can run through direct or managed coordinator routes. Hetzner Desktop requires a managed coordinator. Other providers are rejected before OpenClaw allocates an unsupported desktop worker.
OpenClaw also now requests XFCE explicitly during warmup. That removes the dependency on whatever desktop environment happens to be implied by the provider path.
The Browser and Terminal launchers were tightened as well. Generated launchers validate fixed environment facts and invoke trusted launcher paths without sourcing provider-owned environment files. In practice, that keeps provider metadata in the role of data instead of letting it become shell input.
The Control UI help and public Cloud Workers guide were updated to describe the supported routes more accurately, so operators see the same contract the runtime enforces.
Why It Matters
Cloud Worker Desktop is the sort of feature where small setup assumptions can become expensive operational failures. If a provider route is unsupported, the best time to say so is before allocation. If a desktop environment is required, the runtime should request the one it expects.
The shell boundary is even more important. Agents routinely work with generated files, environment handoffs, and provider metadata. A hard split between "read these facts" and "execute this input" keeps that workflow easier to reason about.
This PR does not claim to enable every desktop route. It does the opposite: it narrows the contract so supported AWS and Hetzner paths are clearer, while unsupported paths fail early with actionable configuration errors.
Evidence From The PR
The PR reports focused Crabbox tests passing, including 114 worker-provider tests and the 120-test Crabbox extension suite. Extension typechecks, lint, package-boundary checks, import-cycle checks, and documentation checks passed.
UI evidence included the Cloud Workers settings end-to-end test passing and a 10-run local stress pass. CI was green on exact head b4980272d1fd251658827f933415aecc030e674e.
The route coverage proves direct AWS, coordinator-backed AWS, managed Hetzner, pre-allocation rejection for direct and registered Hetzner, unsupported-provider rejection, explicit --desktop --browser --desktop-env xfce, and launchers that do not source provider environment files.