Repository navigation
cmux NEXT: a restored terminal pane comes back without a key press - #23145
Conversation
…led attaches (red, #23029) A restored pane said Restoring… and came back only when a key cut its backoff short. These cases fail on the base: the restore backs off to 30 s and offers Retry after 8 tries, and a connection that comes back while an attach waits for its replay is dropped. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…3029) A restored terminal view whose attaches fail while the daemon is busy backed off like any dropped link, 500 ms doubling to 30 s, still saying Restoring…, and only a key press cut the wait short. A restored view that has not shown content yet now retries every 2 s at most and keeps saying Restoring… for about the same 90 s before it offers Retry. An event that re-attaches (the daemon connection back, a key, focus) that arrives while an attach is in flight is no longer dropped: if that attach fails, the next one opens at once. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…e Retry shows (review, #23029) The 2 s cap now ends with the restore's quiet period (about 90 s): a daemon that never answers is not asked every 2 s by every restored pane for good. The test pins that, and no longer leans on the retry count a restore carries past going live. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Correctness review (subagent), head 3008042 → resolved at 7791cdf No correctness bugs found. The reviewer traced the reducer by hand. Both new tests fail on the base (efe6e37) and pass with the fix, and The reviewer checked these paths and found no issue:
Findings and resolution:
|
|
cmux status (one comment, edited in place; each line is updated by the job that owns it) Review App of this head (app.zip, kept 1 day)
Not verified: macOS jobs did not run: compile and app tests were skipped on CI passes on Written by Tour of Path-selected interactions
Core UI (before): DEGRADED — 19 ok, 1 unavailable
Screenshots (15)1. Launch
Screenshots (15)1. Launch Tours are data in |
|
Found 28 test failures on Blacksmith runners: Failures
...and 18 more test failures. View all on Blacksmith
|
|
Bead |
|
Shipped in:
|
) release-notary has been red on feat-cmux-next since #23145 added this highlight with neither a tryIt action nor a docs link, which validate.py requires. It now links https://cmux.com/docs/session-restore, like acp-shutdown-keeps-agents.md. Agent-Session: https://cmux.com/deeplink/agent?harness=claude&session=01a15ba2-c7ad-7850-9e71-5b51f1c9ed9f&host=cosmic-gray Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
































Summary
Fixes #23029. A restored terminal pane in cmux NEXT, usually an agent, stayed on "Restoring…" and loaded only once the user typed.
Cause. A restored view whose first attaches fail (the daemon is busy or slow to answer while restoring) re-attached by itself with the same backoff as any dropped link: 500 ms doubling to 30 s. A key press is the only thing that cuts that wait short; input typed while an attach is in flight is just queued. So the pane sat on "Restoring…" for up to 30 s between tries, and after 8 tries it said "Disconnected: could not attach" while still retrying. A second, smaller hole: a re-attach event (the daemon connection came back, a key, focus) that arrived while an attach was in flight was dropped. If that attach then failed, the view waited the full backoff.
Change (
TerminalAttachMachine, the reducer every terminal view's attachment runs on):restoreBackoffCap). It keeps saying "Restoring…" for about the same 90 s as before (quietRestoreReconnects), then offers Retry and backs off as before, so a daemon that never answers is not asked every 2 s for good.reattachRequested). If that attach fails, the next one opens at once.Views that already went live, hidden views and the non-restore path keep their old behavior.
Testing
Regression tests in
Packages/macOS/CmuxNext/Tests/CmuxNextAppTests/TerminalRestoreAttachTests.swift, committed red first (efe6e37) and then fixed:aRestoredViewKeepsRetryingWithinTwoSecondsUntilItFirstAttaches: about 90 s of failed attaches stay within 2 s of each other and still say Restoring; then the view goes live by itself.theConnectionBackDuringAnAttachReattachesAtOnceWhenThatAttachFailsaRestoreThatNeverAttachesOffersRetryAndBacksOffAsBefore(review follow-up)Focused command, fleet step:
cmux-ci run --class light --script scripts/ci/package-test-lane.sh --arg=suite --arg=Packages/macOS/CmuxNext --arg=TerminalRestoreAttachTests,TerminalAttachRetryTests --ref <sha>, at the red commit efe6e37 (--red) and at the fix head 7791cdf. Results:d22d2be53019945e16320275on aws-m4pro-5:TerminalRestoreAttachTestsfailed, 2 of 2 tests and 69 issues. On the base the restore waits backoff step 38 and more, says Disconnected after 8 tries, and drops the in-flight reconnect.1f6a32d544646acf5baf96db: all 3TerminalRestoreAttachTestspassed, and bothTerminalAttachRetryTestsstill pass. The head 346a568 adds only the release-note file on top of that.Observed / Not run
Observed in the cmux NEXT GUI: tagged builds driven only through their control socket and the bundled
cmuxCLI, launched withopen -gso the user's focus never moved. Real Claude Code was idling in the visible pane. I used Quit and Keep Sessions, then relaunched withCMUX_NEXT_DEBUG_SLOW_ATTACH=10:200(the debug seam that makes each terminal's first 10 attaches fail, as against a busy daemon). There was no input after the relaunch. Link states are fromdebug.surfaces:18611e5c(tag23029-restore-waits-input-base), run 1346a5681(tag23029-restore-pane-waits-input)Also run on the base: the repo's
scripts/cmux-next/restore-journey.py --continuity --variants quit,reboot, plus plain quit and reboot without slow attaches. Every visible terminal came back live within 2.5 to 6.5 s, so the bug needs failing attaches to show. The journey's reboot terminal-agent rows fail outside a capture slot because its shell can't find the test CLIs; that is unrelated.Not run:
window.screenshotruns only for a person, and the banner's look is unchanged; only its timing changed.Correctness review by a subagent found no bugs. It flagged one risk, fixed in 7791cdf: the 2 s cap now ends with the quiet period. It also raised two nits: a doc comment, now reworded, and the retry count carrying past going live, which is existing behavior that bounds a flapping link; the test no longer leans on it.
Changelog
Fixed: A restored terminal or agent pane that says "Restoring…" now comes back by itself, without a key press
Proof
The before/after link timelines above come from the real app in tagged builds.
🤖 Generated with Claude Code