[teamleaderleo]

Summary

cx-jniyz.1, the Swift half of cx-jniyz item (b). When cmux-tui is stuck, the app's launch window and the App Store's not-connected banner showed the failure but offered no way out.

Both now have two buttons:

• Retry Now fires DaemonService.retryWake.
• Restart cmux-tui appears only after a plain server ensure has failed: a restore timeout, the ensure call itself timing out, or server.unavailable. The verb can't tell a stuck owner from one still restoring, so the restore bound has to pass first. A later successful ensure hides the button again.
  • It asks first, in the app's window-scoped dialog (cmux.dialog.restartDaemon): "Restart cmux-tui? cmux-tui is not responding. Restarting it stops the stuck process and starts a new one. Terminals running in it may be lost." Buttons: Cancel / Restart.
  • It then runs the app's ensure command with --replace-unresponsive added, and fires retryWake whether that worked or not.
  • The replace prints nothing for up to 20 s, so the call allows 30 s of silence before restore progress applies, with a hard cap of 180 s.
  • A server.replace_* refusal (exit 3) shows "cmux-tui could not be restarted. Try again in a moment." The refusal code goes to Copy Details.

Remote machines get neither button: there is no launcher for them.

Where the code is:

• How each ensure ended is recorded in DaemonLauncher+Replace.swift.
• The state and actions are in DaemonRecovery, owned by DaemonService.
• The buttons are in DaemonRecoveryControls.
• The App Store banner uses a small AppsRecovery hook. Its accessibility changed from .combine to .contain so the buttons can be pressed.

The 7 new strings are in all 21 languages. The translations are machine-made and need a human review.

Testing

• New test: DaemonRestartTests. A stand-in cmux-tui script runs on the app's real startup path; no real daemon is started and no process is signalled. It checks that Restart is hidden before a failed ensure and offered after it, and that pressing it runs ensure with --replace-unresponsive and then retries. It also covers a refusal.
• Red (test commit 6db7e84, fleet run-swift-testing-suites.sh Packages/macOS/CmuxNext, job af884d75c1e513231215d6df): only DaemonRestartTests failed. The app reached the failure screen, but the buttons were missing: (retry → nil) != nil, (shown("daemon.restart") → nil) != nil.
• Green (758e3ef, jobs 599df8b981aa8790145610b8 and 558a20f6d216e1cde74136d8): DaemonRestartTests passed in both runs (336 suites).
  • Both runs had one failure in SidebarInsertWhileDisplayAsleepTests. This PR doesn't touch that suite. It came in with Skip motion while the display sleeps so inserted rows show #20663, only runs when the host's display is awake, and passed on the headless red host. Not yet proven to be a base failure.
• Release compile of 758e3ef (fleet, isolated, job f4ef136ef8f5f67e4ce6f78b): BUILD SUCCEEDED on Xcode 26.6. There is no Xcode 27 compile receipt yet; the bead asks for one.
• Local checks: crash_ratchet.py, check-no-godfiles.sh (no file grew past its limit), check-concurrency.sh, check-system-blue.py and check-l10n.sh (21 languages, 0 errors) all passed.
• Not yet done:
  • the GUI proof from the bead (fleet app, SIGSTOP its own daemon, press Restart through the debug socket, see a new pid);
  • light and dark captures of both surfaces;
  • the App Store banner path has no test of its own;
  • restart behaviour is not yet agreed with the PTY-holder lead.

Changelog

Added: Retry Now and Restart cmux-tui on the not-connected screens when cmux-tui stops responding

Target

The launch window's connecting and failure screen (DaemonConnectingView), the recovery controls, the App Store banner's recovery actions and their 12 strings live in a new CmuxNextDaemonRecovery target (SW14). CmuxNextApp keeps only the wiring in WindowController and AppsService. CmuxNextApp drops to 113,559 lines: 170 under base (113,729), 133 under the cap (113,692). That also clears the base's +37 over the cap from #20709, which #20883 fixes separately. ci-target-graph.json is updated by hand to match; the cmux-next generated files job checks it.

Proof

Captures (fleet DEV builds of 758e3ef and its base; method and PID evidence in this comment)

Launch window failure screen (owner SIGSTOPped, no saved layout):

	base	head
light
dark

App Store not-connected banner:

	base	head
light
dark

Restart flow (head): Restart cmux-tui, confirm, "Restarting cmux-tui…", reconnected about 11 s after the press (owner 68203 → 67513).

Full quality: pr20765-head-restart-flow.mp4

light	dark

🤖 Generated with Claude Code

---

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

---

Summary by cubic

Adds Retry Now and Restart cmux-tui to the not-connected screens so a stuck cmux-tui no longer leaves the launch window and App Store banner at a dead end. Remote machines get neither button, since they have no launcher.

• Retry Now fires the service's retry wakeup immediately.
• Restart cmux-tui appears only after a plain server ensure failed the way a stuck owner makes it fail (restore timeout, no answer, or server.unavailable). It asks for confirmation first, then runs the app's ensure command with --replace-unresponsive and retries the connection; a refusal shows an error and leaves Retry Now.
• A cancelled ensure no longer hides Restart, and a successful ensure clears an earlier Restart failure so it does not resurface on a later disconnect.
• The launch screen and recovery controls moved into a new CmuxNextDaemonRecovery target; DaemonRestartTests covers the flow against a stand-in cmux-tui script on the app's real startup path.

Also in this branch

• A strip's tab bar lays out for where its pane rests, so its tabs move rigidly with the column instead of being pinned to the traffic lights while the strip camera scrolls; a moving column keeps the larger traffic-light inset until it rests.
• A top-item selection repaints only the old and new sidebar item, with no band update or list reload; the perf gate budgets 0 row configures and band updates and names list reloads by caller, and strip-scroll-check.py verifies strip recordings frame by frame.

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

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

• Configuration used: Repository: manaflow-ai/cmux/.coderabbit.yaml
• Review profile: ASSERTIVE
• Plan: Advanced
• Run ID: c3b51373-544c-4638-a9f9-2d3d83be9be1

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

all web/size checks green

[github-actions]

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

CI passes on 3eaf574a29 (run 39130809160 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.

[teamleaderleo]

In-app proof: Retry Now and Restart cmux-tui (fleet DEV builds)

These captures are from head 758e3eff1c71a4778c31d0287b8f7a839286b10b (fleet job 40d1c48853b925ee1515cdba) and its merge base with feat-cmux-next, a2ea1b0e5f661ddad466371bb13b3399482f5766 (job 7c804e96c8a03a6d8e102de6). Both are Mac-builder DEV builds, run on capture slots on cmux-mac-mini-cua-4. The current head 50786b8de5b725ed2517055c8e36d36ec5d37afd came after these builds; it only changes logic (a cancelled ensure leaves the Restart gate alone, and a successful ensure clears a stale restart failure), with no UI or string changes. It wasn't rebuilt or captured.

How the owner was made stuck. Each app was launched once so its own cmux-tui --headless --session cmux-app-… owner came up, then quit with quitKeepSessions. That owner was then SIGSTOPped by its exact pid (the only cmux-tui of that bundle with that session that isn't a terminal host), and the app was relaunched against it. Nothing else was signalled. Base stills were taken after 135 s or more, past the restore bound.

Launch window failure screen

The capture deleted this tag's launch-snapshot.json and sidebar-snapshot-v1.json before the relaunch. With them present, the window draws the last layout instead of this screen (see "Found along the way").

	base	head
light
dark

App Store not-connected banner

This was relaunched on the stuck owner with the launch snapshot kept: the last layout is drawn, then appStore.show opens the store.

	base	head
light
dark

On head, Retry Now shows at once (banner text "still starting its background service"). Restart cmux-tui joins it after the first plain ensure fails, about 135 s after relaunch, when the text changes to "taking longer than 2 minutes". On the launch window it appeared 124 s after relaunch. Before that the window shows "couldn't start its background service" with Retry Now and Copy Details only. Base shows the same texts with no buttons.

Restart flow (head)

Full quality: pr20765-head-restart-flow.mp4 (frames from debug.window_snapshot at about 4 fps; the dark frame in the middle is me switching appearance for the dialog still).

light	dark

Restart cmux-tui was pressed by an AX click through cua-driver. That opened cmux.dialog.restartDaemon with the PR's title, body and Cancel / Restart buttons, and debug.dialog {press: "restart"} answered it. The window then showed "Restarting cmux-tui…" with both buttons disabled. About 11 s after the press it switched to the workspace.

PID evidence (launch-window run):

• Old owner: 68203, in state Ts (stopped) from before the relaunch until the press.
• About 10.6 s after the press, 68203 no longer existed (ps -p was empty) and 67513 was the only owner listening on cmux-app--085de0c4.
• App log, com.cmuxterm.app.next:app.daemon: cmux-tui restart: replaced, pid 67513.
• The window then showed workspace-1 again, so the app had reconnected.

Retry Now (pressed once, on the launch window, owner still stopped): nothing visible changed for 33 s. The buttons stayed enabled, there was no status line, and the owner stayed Ts. That fits firing retryWake while the owner can't answer: the new ensure is still pending. Restart stayed offered.

Found along the way (not from this PR)

• A stuck owner on a later launch never shows the failure screen. If the daemon's launch snapshot exists, a relaunch draws the last layout (workspace-1 and its New Tab page) and nothing on screen says cmux-tui isn't connected, even 220 s in. Neither button is reachable unless you open the App Store. In practice, most stuck-owner launches will look like this, not like the screen above.
• A stuck owner while the app is connected goes unnoticed. With the app connected and the App Store open, SIGSTOPping its owner produced no disconnected banner within 200 s.
• The launch window's failure line is clipped on base and head alike: "…This is taking longer than 2 minutes;" loses "cmux keeps trying." (the banner shows the full text).

Not verified

• The restart-refusal path (server.replace_*, "cmux-tui could not be restarted"), the Cancel button, and Copy Details content.
• Restart pressed from the App Store banner. Only the launch window's Restart was pressed; the banner's buttons were seen but not pressed.
• Whether terminal hosts are adopted across a restart: these runs had no open terminals.
• Real keyboard and mouse input: the slot runs with CMUX_NEXT_NO_ACTIVATE, so presses went through AX and the debug socket.
• 50786b8de5b725ed2517055c8e36d36ec5d37afd itself, which differs only in the logic noted above.

Cleanup: each run resumed or replaced the one pid it stopped, quit through quitEndSessions, removed its tag's state and released its slot lease. After release, nothing from these build tags was left running on cua-4.