[teamleaderleo]

A Cloud start with no folder could pass the machine's existing workspace folder into remote start, reopening a prior chat. This keeps the no-folder path folderless for Cloud owner links so the daemon allocates the fresh per-chat ~/chats/<chat-id> directory, while non-Cloud peers retain their workspace fallback.

Leo asked that “I want us to be able to do this too”: a no-project Cloud chat should start immediately in its own fresh chat.

Tests: AgentTabRemoteStartTests.aModernCloudDaemonReceivesNoFolderForRustToChoose covers a stale workspace folder and verifies no cwd is sent. python3 scripts/cmux-next/prepush-gate.py passes.

Agent session: agent session

---

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

---

Summary by cubic

Fixes Cloud starts with no folder so they use a fresh chat directory instead of reopening a prior chat.

Previously, a Cloud start with no folder could pass the machine's existing workspace folder into the remote start. Now Cloud owner links stay folderless so the daemon allocates a fresh ~/chats/<chat-id> directory, while non-Cloud peers retain their workspace fallback.

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

[github-actions]

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

Review ecafc24: 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=pr31186 -f ref=lane/cloud-home-fresh-chat -f platform=macos -f backend_mode=local

Shipped in:

• cmux NEXT nightly 1.0.0-nightly.4133598742701 (1e1948befb)
• cmux NEXT nightly 1.0.0-nightly.4133716725501 (d30463325c)
• cmux NEXT nightly 1.0.0-nightly.4133769596201 (0272db645e)
• cmux NEXT nightly 1.0.0-nightly.4133822529301 (68e3df851b)
• cmux NEXT nightly 1.0.0-nightly.4133907849701 (c2ef233b76)
• cmux NEXT nightly 1.0.0-nightly.4133963836301 (48e4448d11)
• cmux NEXT nightly 1.0.0-nightly.4134024448601 (94322a6ccf)

[blacksmith-sh]

Found 2 test failures on Blacksmith runners:

Failures

Test	View Logs
test_runtime_added_app_capabilities_are_runtime_only (main.StaticCapabilityRuntimeO nlyTests.test_runtime_added_app_capabilities_are_runtime_only)/ test_runtime_added_app_capabilities_are_runtime_only (main.StaticCapabilityRuntimeO nlyTests.test_runtime_added_app_capabilities_are_runtime_only)	View Logs
test_the_repository_highlights_validate (main.DigestTests.test_the_repository_highl ights_validate)/ test_the_repository_highlights_validate (main.DigestTests.test_the_repository_highl ights_validate)	View Logs

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

[teamleaderleo]

Review (subagent claude-opus-5-5 medium): SHIP at ecafc24

A Cloud start with no folder (ownerLink set) no longer falls back to the workspace's earlier remote folder, so the daemon makes a fresh ~/chats/ instead of reopening the previous chat. Restored tabs and session links exit earlier and are unaffected, folder starts still win, non-Cloud hosts keep the fallback, and idempotency is unchanged. The test fails on base. CmuxNextApp +1/-1.

Follow-ups:

• A Cloud daemon without supportsNoCwd now gets its listed work folder instead of the workspace folder (harmless, but a behaviour change).
• Add a test that a non-Cloud start (ownerLink nil) still uses remoteFolder.