[teamleaderleo]

Summary

The no-folder Cloud start updates an outdated machine before opening the chat tab (#31145). It waited only for the machine's link to change, not for the capability it needed. A new link can come up before its handshake advertises agent-session-tabs-v1, so the open was refused although the update had worked.

A DEV end-to-end capture of a799d97 showed this: the first start failed with "this machine's cmux-tui cannot hold agent chat tabs yet: update it", and the next send's retry on the same machine succeeded.

CloudOutdatedMachine.updateBeforeUsingCapability now waits, still bounded by 90 s, for holds() itself. holdsTabs reads the observable daemon store's identity, so the wait wakes on the new handshake rather than polling. The link parameter is gone, so CmuxNextApp loses one line.

Leo's ask (the no-project Cloud chat): "i want us to be able to do this too".

Testing

• New CloudOutdatedMachineTests.aNewLinkWithoutTheCapabilityYetIsWaitedFor: the update returns, and the capability arrives one turn later.
  • On base, the old wait returns at once on the link change: holdsTabs is false at return, and the open is refused.
  • On this head, it waits until the capability arrives.
• The existing three tests still cover update-then-capability, a bounded timeout and an already-current machine.
• prepush-gate.py: no new violations, app_lines -1.

Observed / Not run

• Observed: the capture result above, and the prepush gate.
• Not run yet: the Swift suite and the app compile, which run on the fleet after push.

Changelog

Fixed: a new Cloud chat no longer fails its first start right after the machine updates.

Agent session: agent session

🤖 Generated with Claude Code

---

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

---

Summary by cubic

Fixes the no-folder Cloud start so a freshly updated machine no longer refuses its first chat open. The update wait now checks for the agent-session-tabs-v1 capability itself, not just for the link to change; a new link can come up before its handshake advertises the capability, which previously caused the open to be refused even though the update had succeeded.

• CloudOutdatedMachine.updateBeforeUsingCapability now waits on holds() (bounded by the same 90 s), waking on the new handshake via the observable daemon store instead of polling.
• The unused link parameter is removed from the method and its call site.
• Adds a test where the capability arrives a turn after the link change; the existing tests for update-then-capability, timeout, and already-current machines still pass.

^{Written for commit 0fb6eef. 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 0fb6eef: 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=pr31995 -f ref=lane/cloud-update-waits-capability -f platform=macos -f backend_mode=local

Shipped in:

• cmux NEXT nightly 1.0.0-nightly.4141172405601 (3dfea901d7)
• cmux NEXT nightly 1.0.0-nightly.4141347814401 (8dc078cb03)
• cmux NEXT nightly 1.0.0-nightly.4141505439501 (f2381d86dd)
• cmux NEXT nightly 1.0.0-nightly.4141626810501 (a7f48bb820)
• cmux NEXT nightly 1.0.0-nightly.4141702888901 (666ead5781)

[teamleaderleo]

Review (subagent claude-opus-5-5 medium): SHIP at 0fb6eef. Follow-ups: none. The wait wakes on DaemonStore.identity (@observable) through holdsTabs; the daemon object is stable across the update; a failed update or missing capability still ends within 90 s with the caller's refusal; the new test fails on the old link-change wait.