Computer pool: manage per-bot desktops across Mac and Windows hosts

[lightcloud00]

Problem

Per-bot Local VM mode can run two desktops on one OpenMausBot host, and the Existing VM connector can attach one user-managed Linux guest. Neither path lets one OpenMausBot control plane assign bot A to a Mac-hosted desktop and bot B to a Windows-hosted Podman desktop.

This leaves multi-machine users choosing between two separate OpenMausBot apps or concentrating both desktops on one physical host.

Proposed contract

• Pair a bounded OpenMaus computer worker running on each trusted host.
• Give each worker an immutable ID plus advertised capabilities such as platform, runtime, capacity, and desktop readiness.
• Store a per-bot worker target; never store raw SSH keys, bearer values, or host credentials in bot config or runtime events.
• Route lifecycle, screenshot, and control calls through an authenticated worker protocol with hostname and origin pinning, short leases, timeouts, and fail-closed reconnect behavior.
• Prefer Podman on Windows and the supported local runtime on macOS.
• Keep one interactive human control lease per desktop and make the two-up workspace switch ownership explicitly.
• Treat an unreachable worker as unavailable without stopping healthy desktops on another worker.

Acceptance

1. Pair one macOS worker and one Windows 11 / Podman worker with one OpenMausBot control plane.
2. Assign two bots to different workers and start or reuse one isolated desktop on each.
3. Show both desktops in the two-up workspace while both bot turns can continue.
4. Switch human control without overlapping input ownership.
5. Restart the control plane and recover worker identities, per-bot assignments, and safe lease state.
6. Disconnect either worker and prove the other remains usable.
7. Prove credentials and viewer URLs never enter config snapshots, task events, logs, or exported packages.
8. Cover macOS, Linux, and Windows CI with a fake-worker protocol plus one exact Windows Podman acceptance receipt.

Related

• Local VM: show two per-bot desktops in one app window #353 / PR Local VM: add secure two-up workspace and Chief status awareness #365: two-up workspace and per-bot Local VM behavior on one host
• Local VM connector: support an existing CUA-enabled VM #254 / PR Add Existing VM connector support #358: validated Existing VM transport
• Local VM: only one bot at a time — is the single shared instance intentional, and could it become per-bot? #187: original per-bot Local VM request

This issue is intentionally separate from BYO VPS: the current VPS contract is an x86_64 Linux Docker target, not a Windows worker pool.

[lightcloud00]

Fresh Windows capacity evidence and current boundary

A read-only Windows preflight reports ready for two desired instances: Podman 5.8.3, a running WSL machine configured with 6 CPUs, 8 GiB memory, and 40 GiB disk, plus one currently running managed OpenMaus desktop. No container or Podman machine was restarted or mutated.

Today's supported two-desktop path remains same-host: run OpenMaus on Windows, choose Local VM Per bot, set maxInstances: 2, create one desktop for each bot, then use the two-up workspace. Both desktops can run/watch, with one interactive control lease.

This issue remains necessary because maxInstances: 2 does not pool one Mac desktop and one Windows desktop. The missing work is authenticated host registration/health, per-bot host assignment, lease routing, restart/failure isolation, fake-worker CI, and Windows Podman acceptance for the multi-host control plane.

[lightcloud00]

Windows preflight receipt clarified

A fresh read-only run still reports Podman 5.8.3, a running WSL machine (6 configured CPUs, 8 GiB configured memory, 40 GiB disk), and one running managed OpenMaus desktop. The receipt now explicitly emits capacity.assessment: observed_only and thresholds_applied: false.

Therefore status: ready means the runtime and inventory probes succeeded; it is not evidence that two desktops were started or that a resource threshold was admitted. Exact two-up Windows acceptance remains separate, and Mac+Windows pooling still requires this issue’s worker protocol.

[lightcloud00]

Opened two stacked PRs toward this: #533 (control plane) and #534 (the guest-side companion, which contains #533's commits because a cross-fork PR cannot base on a fork-only branch).

Against the acceptance list, honestly:

• 8 — fake-worker protocol on CI: done. 54 tests drive the whole readiness ladder for both platforms through an injected SSH runner, so no guest is needed. The Windows Podman acceptance receipt is not done.
• 7 — no credentials or viewer URLs in config, events, logs or exports: implemented. Only the SSH alias and public digests are persisted, and the transport identity is stripped before a worker is described to a bot, a device client, or a task event. Not yet proven by an export audit.
• 1–6: not done. These need two real hosts, and I have not run them.

Two design points worth your call before this goes further:

Podman vs. the real desktop. The proposed contract prefers Podman on Windows. These PRs instead drive the interactive desktop through CUA Driver on both platforms, because items 3 and 4 are about human-visible desktops and explicit control handoff, which a headless container does not give you. That is a deliberate divergence, not an oversight.

Overlap. #358 proposes its own SSH-alias VM transport and is currently conflicted; I did not fold it in, since which transport wins is a maintainer decision. #365 already provides the two-up workspace that item 3 asks for, so nothing here duplicates it.

One thing the PRs make explicit and I would rather flag here too: macOS Accessibility and Screen Recording cannot be scripted. They are granted per-binary, SIP blocks writing the TCC database, and replacing the driver binary silently revokes them. So the readiness probe re-reads the live grant on every poll instead of trusting setup, and there is a one-time manual step at the guest's screen that no amount of automation removes.