cmux NEXT Cloud: Worker machine exec, files and credential recovery (cmux-platform#89 C2)

Merged
TE
7d ago
+395-125

Part C2 of manaflow-ai/cmux-platform#89, the app side of "secrets delivery and credential recovery on Worker machines". Leo, 2026-10-30, on building the app-server cloud path now instead of after the Oct 31 demo: "well why can't we just.... do our best now?"

Pairs with cmux#27922 (C1, owner answer), cmux#27940 and cmux#27943 (A). Needs cmux#27920 (cloud-np-b: the cmux API's /v1/cloud/machines/{m}/exec and fs/* routes) deployed before it does anything on staging. Until then a Worker machine's calls answer 404, which is no worse than today's refusal.

What

A Worker machine (the Cloud app-server link) has no classic /api/vm row. So cmux cloud deliver-secrets stopped at its first read ("This machine has no finished machine config yet"), apply-machine-config failed the same way through /api/vm exec, and credential recovery and the New Cloud Workspace provider step were turned off. Claude then started signed out on a Worker machine (cmux#27778 review, comment 6514080989).

  • CloudAPIClient.workerMachines(baseURL:accessToken:teamID:) sends the same exec and fs requests and reads the same answers, under /v1/cloud/machines/{id}/ on the cmux API origin the app already uses (ownerAPIBaseURL). It authenticates as the person's Stack session (access token) in the cmux team named by x-cmux-team (the install token's team claim), as CloudOwnerAPIClient does for the Worker's acpmux routes. It never sends this Mac's install token: a Mac install's grant has no execute, so the route would refuse it with a 403 (backend domains/user.ts, cloud-client-session.ts). No Stack refresh token and no X-Cmux-Team-Id go to that origin, and pinning the app's Stack team leaves the cmux team alone. The classic client's paths and headers don't change.
  • CloudService.machineAPI is the classic client on the legacy link and the Worker client on the app-server link. Every machine exec and file caller goes through it: deliver-secrets (config read, receiver, ticket), apply-machine-config, credential recovery (install and restart), the New Cloud Workspace provider step and repo setup, the Codex broker target (whose owner check and liveness read the machine's app link and the app's record on that link), cmux vm exec and file verbs, the tools probe, the network enrollment, Open Desktop's host start, machine updates and the VM host switch. List, create, stats and other machine-record calls stay on api. cmux cloud setup-github stays on /api/vm for now: the defaults guard's tunable-source fingerprint covers CloudGitHubHandlers.bind, so it moves in its own follow-up.
  • Credential recovery (cloudCredentialTransferIsAvailable, CloudPresenter.recoverCredentials, the tab's cloudCredentialRecoveryAvailable) and the wizard's "Provider credential setup" now work on both links once signed in.
  • CloudAPIError also reads the Worker's nested refusal, {ok: false, error: {code, message}}. Its x-cmux-vm-error header already carried the code.

The cmux-machine-env hook is still installed by apply-machine-config's own applier (exec and fs/write), as on the legacy link.

Risk

risk:high: auth, because a credential goes to a new route. The Stack access token only goes to the cmux API origin, which already takes it for the approvals routes. The server gates each call on the caller's use of the machine's team.

Tests

Red tests first (0aa517a49de), then the fix:

  • CloudWorkerMachineFilesTests: exec, fs/read and fs/write go to /v1/cloud/machines/{id}/... as the person's session (Bearer <access>, x-cmux-team: <cmux team>), never an install token, with no refresh token or X-Cmux-Team-Id, and pinning a Stack team keeps the cmux team. The 0c35c6527dd red test would have caught the 403 the review at a4541211665 found; the classic client keeps /api/vm and its headers; a nested Worker refusal reads its code and message.
  • CloudCredentialRecoveryTests: recovery is available on the app-server link once signed in, and off when signed out.
  • The Codex broker target on a Worker machine never calls the classic routes.

Observed / Not run

  • Observed: scripts/cmux-next/prepush-gate.py: no new violations (app-size warning only).
  • Not run yet: the Swift suite on the fleet (this lane VM can't run it). The CI results at the head go in a comment.
  • Not run: deliver-secrets end to end on a Worker machine. That needs cmux#27920 deployed to staging.

Changelog

none (the app-server link is a Debug-only path today)

No capture: no UI change beyond an existing message no longer showing.

šŸ¤– Generated with Claude Code

Agent session: agent session