Cloud: every signed NEXT build (DEV and nightly) defaults to NEXT Cloud via the app-server link

Merged
TE
4d ago
+334-50

Every signed cmux NEXT build now talks to NEXT Cloud by default. That covers signed NEXT DEV (com.cmuxterm.app.debug.next) and NEXT nightly (com.cmuxterm.app.nightly.cmux-next). There is no staged flag, no DEV-only default and no Labs gate.

Leo, 2026-10-31: "but there's not really a point to be so baby gloves with a 'cutover' literally we're the only ones using cmux-next's cloud rn". Earlier, on this PR: "you need to do all that stuff we do not care about classic we care about our new cloud".

What a NEXT build uses now

For both bundle ids (CloudConfiguration.nextCloudChannels):

value
link source.appServer
owner API Worker (/v1/ops, /v1/read, /v1/auth/*, /v1/cloud/*)https://cmux-api-development.debussy.workers.dev
sign-instaging Stack project 454ecd03ā€¦ through https://cmux-staging.vercel.app
callbackDEV cmux-next-dev://auth-callback (#28909); nightly cmux-next://auth-callback (its existing scheme, already in NATIVE_SCHEMES)
auth storageKeychain service, fallback-file directory and cmux.auth.* defaults keys suffixed with the staging project id. The first launch never reads the old production session, and that session stays untouched

The endpoint, auth and link environment overrides stay ignored on these signed channels.

Machine actions on the app server link

Before this PR, CloudService's Kill, Pause, Resume, Rename and idle pause still went to the classic /api/vm client, where a Worker machine has no record. They now run the app server ops (cloud.machine.delete, .pause, .start, .rename, .idle_policy.set) through the same approval loop as the other person-started ops. The first-party Cloud page already did this. Sharing was already hidden for link machines. The router-review BLOCK at 744b9927 found this.

Why the development pair

  • cmux-platform's NEXT Cloud runs in development only. cmux-api-development has PLATFORM_MACHINES=on and the agent gateway, and cmux-platform-development binds its CloudDO, UserDO and TeamDO by script_name, so they share one state. The development platform verifies tokens from cmux-api-development's JWKS, so the token this Worker mints is accepted on the platform's own routes.
  • The new machine routes answer only in development. /v1/workspaces/{id}/machine (cmux-platform#262) and /v1/machines/pick (#261) answer 401 (route present, token needed) on cmux-platform-development. They answer 404 on cmux-platform-staging and cmux-platform-production.
  • No environment forwards to the platform yet. No cmux-api environment sets PLATFORM_SURFACES or a PLATFORM binding (backend/apps/api/wrangler.jsonc), so the forwarder from #29400 is off everywhere. Production cmux-api has no PLATFORM_MACHINES, and cmux-platform-production binds nothing. A production cutover would take several infra PRs and new secrets, so nightly uses the same development pair as DEV.

What changes for nightly users

  • Nightly signs in once to the staging project.
  • Its Feed, automations and Cloud now come from the development Worker, as signed DEV's already do.
  • Cloud stays limited to CLOUD_ALLOWED_TEAMS on that Worker.

Unchanged

  • Classic's ids keep production and the legacy link: com.cmuxterm.app, .nightly, .rc and .debug.
  • The NIGHTLY copy of a NEXT build (com.cmuxterm.app.nightly, nightly-next-legacy-identity.sh) and the Stable copy (com.cmuxterm.app.nightly.cmux-next-stable) also keep production and the legacy link.
  • Debug builds keep their explicit overrides.

No capture: configuration-only change, no UI layout.

Validation

CloudConfigurationSignedDEVTests covers:

  • DEV and nightly without overrides
  • endpoint and auth overrides ignored on both
  • 7 other Release identities kept on production (Stable and the NIGHTLY copy included)
  • Debug overrides

CloudSignedDEVAuthPersistenceTests covers the namespaced storage. Fleet results for the exact head are in the comments below.

Not run: a live signed-app sign-in.

Changelog

  • Changed: signed cmux NEXT DEV and NEXT nightly use NEXT Cloud (the development Worker and app-server link) by default.
    Agent session: agent session

šŸ¤– Generated with Claude Code