PR #27895 - manaflow-ai/cmux

Leo, 2026-10-29: "why is there all this weird stuff at the bottom of the sidebar" / "the rendering gets borked there too :(".

What was wrong

Every Cloud machine made from one image snapshot resumes the same warm template terminal.
That terminal's host record names the builder's workspace key, and the clone's daemon claimed it into a workspace with that key (claim_template_terminal).
So every VM from the current image has a default workspace with the same key. That was checked on two live VMs from the image.
The app keys a workspace by its key on every machine (WorkspaceModel.identity). It saw one workspace on several machines: one registry entry, one machine's row drawn under each clone's section, and commands by workspace id able to reach the wrong VM.

Fix

claim_template_terminal creates the template workspace with a freshly minted key.
The registry row places the terminal under that key. The host's record keeps the builder's key only as its recovery hint; placement already reads the SQLite row.
Nothing else changes: same PTY, same screen, same session and terminal binding.

Test

template_terminal_host_is_adopted_by_a_fresh_identity_daemon (cmux-tui/crates/cmux-tui/tests/terminal_host_recovery.rs) now also asserts that the adopted workspace's key differs from the parked host's key. That assertion is committed before the fix (83a51ab6d6d), so the test is red there and green at the head:
./scripts/verify-cmux-tui-hosted.sh --filter template_terminal_host_is_adopted_by_a_fresh_identity_daemon. Results are posted below once it runs.

Observed / Not run

Observed: prepush-gate.py passes, and rustfmt is clean.
Not run yet: the hosted Rust test at either commit.
Not covered: a fork of a running machine still copies its user workspaces' keys. That is a separate change.
Only machines made after the image is rebaked with this daemon get their own key; machines that already exist keep the shared one. For those, the app-side change in #27884 keeps their workspaces out of the sidebar until the person opens the machine.

Changelog

Fixed: Cloud machines made from the same image no longer share one default workspace.

risk:normal

Agent session: agent session

🤖 Generated with Claude Code

Summary by cubic

Fixes Cloud clones made from the same image snapshot no longer sharing one default workspace key.

Every VM from one image resumes the same warm template terminal, whose host record names the builder's workspace key. The clone's daemon claimed it into a workspace with that key, so each machine's default workspace had the same key and the app treated them all as one workspace—drawing one machine's row under every clone's section and letting workspace-id commands reach the wrong VM.

claim_template_terminal puts the template workspace under a key derived from this session and the builder's key, formatted as a lowercase UUIDv8, so each clone gets its own key and a restart derives the same one—a claim cut short between commits resumes on the next start.
A registry holding only that derived workspace still claims the host, so a crash between the workspace's commit and the terminal row's is recoverable.
Once the claim completes, the host's record (its recovery mirror) names the clone's workspace, so a rehost or recovery never places it under the shared key; the builder's key remains only as a recovery hint.
The recovery test asserts the adopted workspace's key differs from the parked host's key and that the host record mirrors it.