What happened
Cua’s October 25 changelog covers Cua Spaces 0.13.0, 0.14.0, 0.15.0, and 0.16.0. Cua Spaces is the company’s application for providing computers to users and their agents. The release is mostly about making those computers easier to provision, identify, operate, and recover when the local application or sign-in flow goes wrong.
The clearest infrastructure addition is in Spaces 0.14. Cua says it added support for E2B and Daytona, plus Hetzner as a bring-your-own-cloud option. It also lists a shared pool of computers, cua share, and a public relay. The changelog does not specify the commercial terms, capacity, geographic availability, or operational differences among these choices. What it does establish is that a Spaces deployment need not be limited to one hosting route: a team can use E2B or Daytona, use a Hetzner cloud it controls, or work with Cua’s shared and relay-oriented options.
On the client side, onboarding now begins with agents rather than a generic setup path. A user can choose any listed agents—or none—for each computer. The release specifically says Codex signs in with the user’s ChatGPT account. Cua also changed the Home screen to be quieter and made “Skip for now” persist after the application is reopened. That is a small product change, but it matters in a workflow where a computer may be prepared for a particular agent rather than only for a human operator.
Several changes target reliability and manageability. Cua Spaces now appears under one name in System Settings rather than as a separate background item. The stable application and Cua Spaces Local retain separate names, settings, and messages when installed side by side; Local hints use cua-local. If sign-in does not return to the app, users can enter a code. Switching to another account now updates the account and the registration of the current Mac. The Spaces page should no longer look empty while computers are still responding, and the menu-bar notch counts only Spaces that are running or starting.
Finally, Cua added more recovery paths. System Status is linked from Help, Settings About, and the troubleshooting guide. The Local uninstall script now removes preferences, caches, web data, relay membership, and Local entries in coding agents. Opening the app displays its window, while the installer retries if Apple’s notarization check stops partway through. These are not new agent capabilities, but they reduce failure modes around installation, permissions, identity, and teardown.
What the archive adds
This is a new fact on a known Cua Spaces story. The earlier Field Note, Cua lets your agents run jobs across every machine, covered the Spaces SDK and its proposition of giving computer-use agents their own desktops, screens, and applications. This release extends that operating surface with additional places to run those computers and more practical controls around setup and maintenance.
Trend signal
This supports Harness architecture outlives model choice. The changelog’s central practical move is not a new model: it is a broader execution layer around agents, including alternative cloud backends, shared computers, relays, onboarding, identity recovery, and local cleanup. Those are harness concerns that remain relevant even as the chosen coding or computer-use model changes.
Why it matters
A computer-use agent is only useful in production if a team can decide where its desktop runs, connect it to the right account, see whether it is alive, and remove it cleanly later. Cua’s backend additions offer more deployment choices, but the available evidence does not establish that all options are equivalent. Teams may prefer a managed provider for speed, a Hetzner deployment for control, or shared resources for experimentation; each choice will likely carry different security, networking, cost, and support implications.
The onboarding and sign-in changes are equally operational. An agent workstation is a stateful environment, so failures in account handoff, registration, permissions, or uninstalling can become workflow blockers rather than cosmetic defects. The release treats those issues as part of the product surface. Builders evaluating computer-use infrastructure should do the same: judge the runtime not only by how an agent clicks through a task, but by how it is provisioned, observed, switched between accounts, and retired.
Limits and uncertainty
The changelog is a product announcement, not a comparative evaluation. It does not state pricing for E2B, Daytona, Hetzner, shared pools, or relays; it also gives no performance figures, security model, concurrency limits, regional coverage, API details, or migration instructions. It is unclear which additions arrived in each of 0.13, 0.15, and 0.16 beyond the explicit 0.14 backend note. The source also does not demonstrate that a team can move an existing Space between backends, nor does it describe how credentials and data are isolated across the new options.
Skill to build now
Create a short runtime selection checklist before attaching an agent to a remote computer. This week, test one representative task across the deployment route you would actually use and record: where the desktop runs, how the agent receives credentials, how account switching behaves, what status signal an operator sees, and how the environment is erased afterward. Include a deliberate failed sign-in and uninstall test. The release makes those lifecycle paths visible enough to evaluate, and they are often more consequential than a successful first demo.
Reader takeaway
Cua Spaces is becoming less tied to a single place to run an agent computer. Its new E2B, Daytona, and Hetzner options are the headline, but the more durable lesson is to evaluate computer-use platforms as managed runtimes: deployment, identity, observability, and cleanup determine whether agents can be used repeatedly by a team.
Open question
Will Cua publish the pricing, isolation model, and operational trade-offs that let teams choose confidently among E2B, Daytona, Hetzner, shared pools, and the public relay?