[teamleaderleo]

Leo: "IN THE ACTUAL PRODUCTION APP IT MAY BE AGAINST TOS" (copying the Mac's Claude/Codex login to a user's Cloud machine), and on 2026-11-01: "yes those are important".

What changed

• CloudStartChat.passesHarnessLogin(isDebugBuild:setting:) is the one switch for every Mac-to-machine login transfer: setting ?? isDebugBuild. The cmux.cloud.passHarnessLogin default wins when set (true on, false off); unset, it is on in a Debug/DEV build and off in release. passesHarnessLoginHere reads it for this process. Before, a Debug build could not turn it off (isDebugBuild || optedIn).
• AgentTabStore.cloudCredentialTransferIsAvailable now also requires the switch (isSignedIn && passesLogin). That one function feeds:
  • the handshake's cloudCredentialRecoveryAvailable (the webview card's "Transfer" offer),
  • syncCloudCredentialTransferAvailability (the native recovery callback),
  • CloudPresenter.recoverCredentials's guard (Claude setup-token and the Codex broker),
  • the new-workspace wizard's credential setup (CredentialAvailability, Claude and Codex broker).
• cloud.startChat's pre-first-prompt pass reads the same switch.
• Tests: the switch's full truth table (CloudStartChatLoginTests) and recovery off when the build does not pass the login (CloudCredentialRecoveryTests).

Production-config DEV build: defaults write com.cmuxterm.app.debug.next cmux.cloud.passHarnessLogin -bool NO ("cmux NEXT DEV"; a tagged DEV build uses its own com.cmuxterm.app.debug.<tag>), then relaunch. defaults delete <bundle id> cmux.cloud.passHarnessLogin returns to the build default. The NEXT nightly (com.cmuxterm.app.nightly.cmux-next) is a release build, so it is off unless set -bool YES.

Risk

Production (release) builds stop offering the Mac transfer from the card, the start-chat pass and the new-workspace setup. With it off, the card falls back to the on-machine sign-in being built in parallel (acpmux + webview card); until that lands, a release build's card shows no transfer button. The wizard then shows its existing "Provider credential setup is unavailable with this Cloud connection." note (follow-up: wording). The switch is read when availability syncs (launch, sign-in/account change), so flipping the default takes effect on relaunch.

Swift stays thin: one pure static function plus its call sites, no new logic. Minimal overlap with #29962 (held), which edits other lines of CloudStartChat+Login.swift.

Agent session: agent session

🤖 Generated with Claude Code

[github-actions]

cmux status _{(one comment, edited in place; each line is updated by the job that owns it)}

Review b36a6f1: HQ feed card · gallery before/after runs · checks

App of this head (app.zip, kept 1 day)

gh workflow run reload-build.yml -R manaflow-ai/cmux --ref feat-cmux-next -f tag=pr30183 -f ref=cloud-transfer-dev-only -f platform=macos -f backend_mode=local

Not verified: macOS jobs did not run: compile and app tests were skipped on b36a6f1ffd; ci-status is green without them.

CI passes on b36a6f1ffd (run 41276006597 attempt 1).
macOS jobs did not run: compile and app tests were skipped: Fast static checks skipped (the macos job needs both to succeed). Re-run CI once they pass, before merging.

Written by scripts/ci/classify_failures.py (ci-failure-attribution.yml); signatures are its SIGNATURES table. A machine verdict is the runner's fault, not this PR's; yours means the failing file is one this PR changes, also red on main that main's latest full suite fails the same way, seen on other PRs that it failed on another pull request's run lately.

Shipped in:

• cmux NEXT nightly 1.0.0-nightly.4130052256501 (28aa638015)

[teamleaderleo]

Owned by an agent session · session

[teamleaderleo]

Review (subagent opus-5.5 medium): SHIP at b36a6f1

The switch is setting ?? isDebugBuild, and every Mac-to-machine transfer path is gated by it: the start-chat pass, the card's recovery handshake, the recovery callback, recoverCredentials (Claude and the Codex broker), and the new-workspace wizard. Fleet app compile passed at this head (job b06ad7b3868fc86687515925). CloudStartChatLoginTests and CloudCredentialRecoveryTests pass (step 4241ff25a4b26110a3db91d5).

Follow-ups:

• In a release build the wizard says "Provider credential setup is unavailable with this Cloud connection." That wording is misleading; it needs its own availability case.
• passesHarnessLoginHere, which reads UserDefaults, has no test of its own.
• A Codex broker that someone already set up through the opt-in keeps renewing outside this switch.