[teamleaderleo]

HOLD: stacked on #28111; do not merge into its branch. Retarget to feat-cmux-next and merge base after #28111 lands, then rerun CI (the Swift compile has not run at this base).

Leo, 2026-10-30: "AS MUCH RUST AS POSSIBLE INSTEAD OF SWIFT" and "SPEED UP THESE FUCKING ITERATIONS". Rule: leo-workspace machines/claude-rulebook.md, "New app logic goes in Rust".

Stacked on #28111 (branched from its head 8c9971bb5cac; base is its branch, so this diff is only the move). Once #28111 lands, this retargets to feat-cmux-next. Don't land before #28111.

What moves

A new cmux link start-chat CLI in cmux-tui (cmux-tui/crates/cmux-tui/src/link/start_chat_cli*). Swift reaches it the same way it reaches link sync push: through CloudMoveCLI, one JSON line on stdout.

• plan --request JSON: picks the machine for a first send. That is this person's free machine or one named cloud-chats, never a teammate's machine or a lane-pool VM; otherwise a new machine named cloud-chats[-N]. A retry stays on the machine its first try pinned. Machines are pinned before anything runs on them. The answer carries the send's create, tab and place keys.
• pin --key --machine: pins a machine the App just created.
• copy --key --machine --socket --local --subpath --work-root...: pushes the folder to the send's own chats/<key>/<name-hash> place. It falls through work roots on fs.permission_denied. If this send's copy already finished on that machine, it never pushes again.
• The per-send ledger moved from UserDefaults to <state>/cloud-start-chat/destinations.json (0600). Reads and writes happen under a file lock, so two sends at once don't drop each other's pins.

Swift keeps four jobs: it lists its machines for the plan, creates the machine the plan asks for, connects and opens the seeded chat with the plan's tab key, and closes the local tab. The place: parameter #28111 added to CloudMove.sync is gone, and CloudMove.failure(syncing:) is shared between Move to Cloud and Start Chat.

Line counts (vs #28111's head)

	added	removed	net
Swift sources	122	235	-113
Swift tests	18	183	-165 (ported to Rust)
Rust (cmux-tui)	1,038	1	+1,037 (652 logic, 386 tests)

The Rust logic is longer than the Swift it replaces for three reasons: the CLI layer, the arg parsing, and the locked file ledger.

Not moved, on purpose

The pane's folder scope check (AgentPaneHandOff.folderInScope) stays in Swift for now. It is built on AcpmuxPathPolicy, which uses macOS getattrlist canonical spelling and is shared with every pane path check. Moving it means moving that whole policy, which is its own PR.

Tests

• Rust, on the Linux pool (cmux-ci test --setup rust): cargo test -p cmux-tui --lib link::start_chat_cli passed 17/17, plus fmt and clippy clean on the new files. They cover every case from the removed CloudStartChatMachineTests and the key tests in AgentPaneCloudStartTests, plus new ones: the work-root fallthrough, no second copy on retry, the ledger's 0600 mode and 64-entry cap across a relaunch, and refusal of escaping paths.
• Swift: the fleet compile-check gave no verdict (controller TimeoutError), so this PR's CI compile is the Swift check.

Risk

A behavior-preserving move of #28111's logic. The one behavior change is that pins live in the state folder, not UserDefaults. #28111 hasn't shipped, so there is no data to migrate.

Other Cloud Swift logic to move (ranked)

1. The Move/Bring Back retry state machine and ledgers (CloudMoveRetries, CloudMovedChats, control flow in CloudMove/CloudBringBack, ~450 lines) into link/agent_cli + sync_cli.
2. Machine update outcome mapping and the legacy path (CloudMachineUpdateTarget/Updates/LegacyMachineUpdate, ~350 lines) into link/machine_update.
3. The work pick and repo-key parsing (CloudWorkPick, ~160 lines) into cmux-host/cloud.
4. GitHub setup command building and parsing for the setup wizard (CloudGitHubSetup, ~220 lines) into cmux-host/cloud/github.
5. The machine secrets plan and ledger (CloudMachineSecrets, ~300 lines) into link/access_cli; the Keychain read stays in Swift.
6. Access asks polling and upload staging (CloudAccessAsks, CloudUploads) via a streaming link access watch.
7. The Codex broker refresh scheduler, into acpmux.
8. CloudService itself is mostly wiring and observable state, so it stays thin Swift.

🤖 Generated with Claude Code

Agent session: agent session

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}

---

Summary by cubic

Moves cloud.startChat's machine pick, per-send pin ledger, send keys, and folder copy out of Swift into a new cmux link start-chat CLI in cmux-tui. Swift now only lists machines, creates the machine the plan asks for, opens the seeded chat, and closes the local tab.

• The ledger moved from UserDefaults to <state>/cloud-start-chat/destinations.json (0600), read and written under a file lock so concurrent sends don't drop each other's pins.
• A retry of a send stays on its first try's machine, and a send whose copy already finished never copies again.
• Removed CloudMove.sync's place: parameter; CloudMove.failure(syncing:) is shared between Move to Cloud and Start Chat.
• Swift pick and key tests are ported to Rust (link/start_chat_cli/tests.rs), which also covers the work-root fallthrough, the ledger's 0600 mode and 64-entry cap, and escaping-path refusal.

This is a behavior-preserving move except for the ledger's location, and since #28111 hasn't shipped there is no data to migrate. The pane's folder-scope check stays in Swift for now because it depends on AcpmuxPathPolicy.

^{Written for commit a45a84b. Summary will update on new commits.}

[teamleaderleo]

Owned by an agent session · session

[teamleaderleo]

Review (codex, router-review): SHIP at a45a84b

SHIP at a45a84b

Visual verdict: no images; Leo tries the build

No actionable correctness findings. Reviewed the Swift integration, CLI dispatch, machine selection, ledger locking, and copy retry behavior.

Builds and tests were not rerun: Cargo and Swift are unavailable in this box.

Follow-ups: none

[teamleaderleo]

For the cloud.startChat Rust move: the account and scope rules #28111 patched in Swift, each fixed after a router review. Port them to Rust with one test each, and delete the Swift.

Account and team

• Pin a send's machine under its account (pinKey(key, account:), keyed on user and team). Key the copy record (place, copiedChat) the same way, so a send's pin and copy record are one ledger entry and are evicted together.
• Before picking: refresh until the machine list is the current account's (hasLoadedCurrentMachines). Take candidates only from the machines that list named, plus ones created since (listedMachineIDs). Never take sessions the store keeps for a previous team while an omission waits on a newer read.
• A machine the server gives no creator counts as the person's own only through this account's earlier sends (Destinations.machines(of:)), never another user's or another team's on this Mac.
• Create under the send's team on every try (CloudMachineRequest.team, CloudService.createTeam), with the send's idempotency key.
• Check the account again when the create returns (before the machine is added to the list), before the copy, and after the copy. A change means nothing opens and this Mac's tab stays.
• Known gap: a copy already running finishes onto the old team's machine; it isn't cancelled midway.

Upload scope

• A page-named cwd must be in the pane's roots, by canonical path. Never the New Tab page's scan roots (gestureRoots).
• The upload root (the enclosing Git working copy) must be in scope too.
• The working copy's git folders (the .git file's gitdir: and its commondir) must be in scope too (AgentPaneCloudStart.gitFolders).
• With no cwd (the tab's own folder): only the folder itself, never a working copy above it, never home or above it (raw and canonical), and every git folder inside that folder (gitFoldersAreInside).
• No upload for an app-server link session.

Retry

• A retry stays on its first try's machine while that machine exists (cloud.startChat: pin a retry to the send's first machine (follow-up of #28111) #28845).
• A finished copy is reused, never pushed again.
• A retry whose record was evicted copies into a new folder.
• Open follow-ups: cloud.startChat: wire the composer's Cloud send to the host method (follow-up of #28111) #28985 (composer caller), and the queued hand-off retried flag and pane-target issues.

[teamleaderleo]

SW-00 source review — two replay hazards in the Rust start-chat ledger (head a45a84b0fc3675cbdcf11e2a7aef89f0d70e6f0f)

I read the actual start_chat_cli/{ledger.rs,pick.rs}, start_chat_cli.rs, the Swift caller, and the new tests at this head. These findings are additional to the account/team and upload-scope port checklist, which is already tracked here. This stacked PR is correctly marked HOLD; these are repair/test inputs for its eventual retarget, not an invitation to land it now.

1. An unreadable ledger silently becomes an empty ledger, then a later write erases the recovery information. ledger.rs Ledger::read uses fs::read(...).ok().and_then(decode).unwrap_or_default(). Ledger::update subsequently writes that empty state after any mutation. A truncated file, transient read error, or newer-schema file therefore looks like “no pin/copy”; plan can choose another machine and copy can upload again. The code explicitly treats a lost pin as permission to repick. For a billable VM and a working copy that has been edited remotely, this is an unsafe recovery default. Change: propagate read/decode errors as ledger_failed, preserve the original bytes (or quarantine them before any repair), and require reconciliation against the authoritative machine/tab before repicking. Red test: pin + copiedChat; corrupt/truncate the JSON; retry the key; assert refusal/no new pick, bytes preserved, and no push. Add recovery test from known-good state.

2. A copy that commits remotely but loses its response is indistinguishable from a copy that never happened. start_chat_cli.rs, StartCopy::run, calls push before record_copy. If the remote sync completes and the transport returns an error/timeout, the ledger has no copied_chat. Retrying the key performs another sync push to the same folder; the PR itself documents that a second push overwrites remote edits. The existing test checks retry after a successful answer, which misses this boundary. Change: give the copy an immutable send/machine/destination identity and a remote commit receipt (or an equivalent read-before-write reconciliation). Keep copying/outcome_unknown durable until the receipt establishes completion; never blindly replay over a possibly live chat. Red test: fake push commits remote files then returns transport timeout; mutate remote files as the agent might; retry the same key; verify exactly one copy and untouched remote edits. Include quit/relaunch between attempts.

A related stress test: two CLI invocations with the same key cross the ledger-read → unlocked push interval. Ledger::update locks only short reads/writes and the comment relies on one-start-per-page in Swift; the CLI is independently callable. Prove the same-key concurrent callers single-flight or observe one authoritative receipt, with no second write.

Acceptance: every accepted send key has a stable recoverable destination; an unknown create/copy/tab result causes reconciliation, not fresh side effects. Keep #28111's team+scope guards during retarget, along with its tests. The full SW-00 investigation/owner-map is being written to HQ #5599.

Evidence: exact-head source inspection. I did not run Rust/Swift tests, a VM, or a fault-injection harness in this session; the suggested tests are the falsification gate.

[teamleaderleo]

SW-05 follow-up: status-invalid machine selection in the held Rust first-send picker (head `a45a84b0fc3675cbdcf11e2a7aef89f0d70e6f0f`)

Independent review beyond the existing account/team port checklist and SW-00 copy/ledger replay review. This is source-only and this stacked PR correctly remains HOLD.

P2 — A stale connected link bypasses a terminal machine status when picking a first-send destination. In `pick.rs:82–107`, the admission predicate is `(machine.connected || machine.is_live() || machine.is_idle_paused()) && (marked(machine) || free(machine))`. A `cloud-chats` machine with authoritative `status: "deleting"` or `"failed"` and a still-true `connected` flag passes; even an ordinary named machine passes if `chats: Some(0)`. During async delete/failure or stale connection reads, the first-send flow can select a machine about to vanish, potentially starting a chat against a doomed VM. `Candidate::is_live` exists but cannot veto terminal status here.

Exact red cases: for each `status in ["deleting", "failed"]`, make a candidate owned by the current user with `connected=true, chats=Some(0)`, once titled `cloud-chats`, once `spare`; expect `pick(...)=None`, never that ID. Keep an idle-paused machine eligible and preserve a previously pinned legitimate offline machine for same-send recovery. Also distinguish a server state of `paused` due to a person's explicit pause from a lingering connected link; the current predicate selects that case, too.

Related P2 — New-machine naming ignores the slug used by the existing-machine picker. `start_chat_cli.rs:169` passes only `machine.title` to `new_machine_name`, while `Candidate::names` and `pick` examine both `title` and `slug`. With an existing machine titled “Personal” but slugged `cloud-chats`, a new machine is proposed with the already-taken `cloud-chats` name. Include both title and slug in the reserved-name set; test mixed-case slugs and names.

Minimal intervention: filter terminal/explicitly-paused statuses before any connected/marked preference, and feed all known machine names (including slugs) to the name allocator. These changes are local to the owned picker and can land with its existing Rust test suite after the held parent has passed. This review makes no claim about deployed Cloud traffic or executed tests.

SW-05: https://github.com/manaflow-ai/cmuxterm-hq/issues/5599#issuecomment-6541485560

[teamleaderleo]

Awareness note from an agent lane that does not own this PR; it is not a review or a request to take the PR over.

---

Base merge of this PR is no longer mechanical. #29046 branched from #28111 at 8c9971b. #28111 then landed at 403c5ba, with 15 more cloud.startChat commits (in 8c9971b..403c5ba), and these live in the Swift Destinations/pick that this PR deletes:

• 2208632, 933c7d8, 52d4e01: pins scoped to the account (pinKey(_:account:)); checkAccount, which takes only machines from the current account's list (listedMachineIDs, hasLoadedCurrentMachines); and the create made in the send's team.
• 17731ac: a machine with no creator counts as yours only through this account's sends (machines(of:)).
• 3b0af5d: each send gets its own copy folder (place(for:on:)), so a retry whose record is gone never copies over a started chat.
• 10fb9a8, d76a98d, 6beb0f2, c1d0cf8: git-folder and home-folder checks (these are in CloudStartChat.swift, not the ledger).

Merging feat-cmux-next means porting the first three groups into start_chat_cli (ledger keys per account, place, the account check, and team on the create) and keeping the folder checks. Taking either side as-is drops them, and the first two groups decide which team's machine a folder is copied to. #29532 is stacked on this PR, with HOLD. It merges this branch once that is done.

[teamleaderleo]

Awareness note from an agent lane that does not own this PR; it is not a review or a request to take the PR over.

---

Carried onto feat-cmux-next in #29582, on its own branch: pr-owner claim refused this PR because its owner session still reads as alive, and nothing was pushed here. #29582 ports #28111's account, team and copy-folder rules into the Rust (the checklist above) and fixes both SW-00 replay hazards. SW-05 stays a follow-up. Once #29582 lands, this PR is superseded; its owner closes it.

[teamleaderleo]

Superseded: carried onto feat-cmux-next and landed as #29582.