[lawrencecchen]

Summary

The first key a person types into a reopened window's focused terminal can arrive before that terminal's surface exists, and then it reaches no view. On the feat tip (d3feb066), 10 of 15 Cmd-Q keep + reopen cycles on cmux21 lost that key (REOPEN-F4, STATUS 4618). The 15 input journals show the rule: the key was kept if and only if the focused pane was the first pane the window showed.

Why it happens: a reopened window shows its panes one new surface per frame (ContentPresentationScheduler), and LayoutRootView.updateVisibility reported the panes that came on screen in a Set's hash order. So the focused terminal got the first frame in about 1 of 3 launches; in the others its surface came 100-200 ms later, after the key. Nothing held a key for a focused terminal whose surface was still to come (the hold existed only for a selection change, PaneSelectionPresenter).

Lawrence's rule (cmux-ad 02:35Z): a restored window gives the keyboard to the restored focused terminal, and any key that arrives before that is held for that terminal (the 1193 lane design) and delivered in order, never dropped.

What changes:

• LayoutRootView reports panes that come on screen together with the focused pane first, then in layout order (never hash order).
• ContentPresentationScheduler gives a queued focused pane the next frame's surface. The other panes keep their order and their pace (one new surface per frame); nothing else waits longer.
• CreationInputCoordinator holds a key-down while the focus names a live terminal of the shown workspace whose surface is not shown yet. The held keys are that terminal's lane (CreationInputBuffer.awaitSurface(of:)), and they run again in order once its view has the keyboard.
• Bound, when the surface never comes: holdLimit (2 s, as every creation hold). Then the keys go to that terminal's view if it has one, else to its daemon terminal by id (send-key, in order). A terminal that closed takes its keys with it, with a log line. They never go to another view. I chose delivery over a drop: the keys are the person's input for a terminal that exists; the daemon accepts them even with no view, as the 1193 lanes do.
• Pays for the new App lines (arch ratchet app_lines): NoActivateKeyboardGuard (AppKit only, no App types) moves to CmuxNextFocusUI (the Focus row of the destination map). Its AppKit host and the waived NoActivateApplicationReference stay in the App. Net CmuxNextApp −94 lines.

Culprit (lead question, STATUS 4872): the dogfood line passes because it has its own fix of the sidebar half, 99c70f7 (ShellWindow.refusesOrderInKeyView, never ported to feat); feat's equivalent #30356 never reached the app because of the stale CCmuxAppFFI pin, which #31684 fixes. This PR reverts nothing: it covers the other half, a key that comes before the focused terminal's surface exists.

Review follow-up (SHIP at 2adbcf9, findings 1 and 2, fixed in 785c45d): a Ctrl/Cmd chord that no app shortcut takes (Ctrl-C, Ctrl-L, Ctrl-R) waits too, also as the first key of an empty hold; app shortcuts (Cmd-T, Cmd-W, Cmd-Q) still act at once. A second cold terminal the focus moves to meanwhile gets its own lane.

The other half of REOPEN-F4 (the focus itself went to the sidebar list that AppKit picks as the window comes forward, because the app's CCmuxAppFFI pin predates #30356) is #31684. The two PRs are independent; both are needed for the journey.

Owner note: LayoutRootView is PL-motion-core's (OWNERS.md); the change is only the order of the presence reports.

Testing

Regression tests (committed first, 19119b7, red on the base):

• FocusedPaneShowsFirstTests (layout): six panes come on screen together, the focused one last in layout order; the reports must be the focused pane, then layout order.
• FocusedPanePresentedFirstTests (scheduler, manual frames): the queued focused pane gets the next frame's surface; the others follow one per frame in their order.
• ColdFocusedTerminalTypeAheadTests (real daemon): a workspace with two terminals, the right one focused, hibernates; with the frame's surface budget spent, the window shows it cold, and a line is typed in that same turn. The line must run whole and in order in the focused terminal and never reach the other one.

Fleet runs, 5 runs each (package-test-lane.sh suite, each suite named 5 times, through proof-step.py). Every ref carries the cmux-tui/Cargo.lock of base-red fix #31654 on top (proof only: the stale lock of #31462 stops the same-tree daemon the real-daemon tests need):

• Red, base 64a2392 + all tests (2b83ec5, job 89e27ee8b3e01c6437fe5988): every test fails 5 of 5. Layout: hash order (e.g. [p2, p5, p3, p6, p4, p1]). Scheduler: ["first", "a", "b", "focused"]. Cold workspace: the typed line never ran in the focused terminal (ran?.matched → nil). Chord: the screen was not cleared.
• Red, previous head 2adbcf9 + the chord test (9f1bea9, job c0327aa23066ae799632832f): the line test passes 5 of 5, the chord test fails 5 of 5 (screen not cleared).
• Green, head 785c45d (b8da1c9, job 219862550bb69953e972bf83): all 4 tests pass 5 of 5.
• Green again after the base merge that brought fix(launch): every visible terminal shows its last frame in a reopen's first frame; launch metric is the last pane #31621 (PresentablePane.showWhileWaiting; the test fakes got an empty one, f40f3c6): head f40f3c6, compile job 9db120984fcfe247833308c9 passed, job 1eac526d941c59400e4ea144: all 4 tests pass 5 of 5.

Observed / Not run

• Observed: the 15 cycle journals of /work/tmp/reopen-video/rounds/r2-feat-marks-quit-keep-hid-light/ (kit cp/reopen-video-kit@d76e5b72c7a): kept iff the focused pane showed first (15 of 15). prepush-gate.py: no new violations; app_lines −94.
• End-result proof: journey reopen-first-key (kit ff80174, review SHIP; REOPEN VIDEO owner, STATUS 4951) GREEN 6 of 6 rounds on builds 6a7e734413dd87dcd6be176e (785c45d + fix(focus): pin CCmuxAppFFI to #30356's release: a sidebar AppKit picks never takes a restored terminal's keyboard (REOPEN-F4, F5) #31684) and 82cfb423248c0d329e2189f2 (436e881 + fix(focus): pin CCmuxAppFFI to #30356's release: a sidebar AppKit picks never takes a restored terminal's keyboard (REOPEN-F4, F5) #31684): 30 Cmd-Q keep reopens with 60 marker keys, each reached its terminal once; 6 kill-all reopens (REOPEN-F5), the line typed 2 s after the terminals showed ran each time. Base feat d3feb066: 3 of 3 red.
• Not run: the key-dispatch bench before/after (review note 4: each key-down now asks awaitedSurface; its common case is two dictionary reads and a tab compare).
• Not covered: a key typed before the reopened window is key at all (no key window: AppKit delivers it to no window). No lost cycle shows this (every key came 60-120 ms after the window became key).

Changelog

Fixed: The first keys typed into a reopened window reach its focused terminal instead of being lost

Proof

No capture: input routing with no visual change; the proof is the test runs and the reopen journey.

[blacksmith-sh]

Found 6 test failures on Blacksmith runners:

Failures

Test	View Logs
main.DeveloperIdAppTests.test_download_prints_the_active_profile_only/ test_download_prints_the_active_profile_only	View Logs
stubs: /System/Library/Frameworks/Security.framework/Versions/A/Security has no stub/ Security has no stub	View Logs
stubs: CoreFoundation.tbd: install-name /System/Library/Frameworks/ CoreFoundation.framework/Versions/A/CoreFoundation, missing 1: ['_CFRetain']/ CoreFoundation, missing 1: ['_CFRetain']	View Logs
stubs: CoreFoundation.tbd: install-name /System/Library/Frameworks/ CoreFoundation.framework/Versions/A/CoreFoundation, missing 1: ['_log2']/ CoreFoundation, missing 1: ['_log2']	View Logs
test_every_compile_job_names_its_warm_sources (main.ThisTree.test_every_compile_job _names_its_warm_sources)/ test_every_compile_job_names_its_warm_sources (main.ThisTree.test_every_compile_job _names_its_warm_sources)	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.}

[github-actions]

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

Review f40f3c6: 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=pr31707 -f ref=fix/p0-reopen-f4-first-key -f platform=macos -f backend_mode=local

web and size checks: green

Shipped in:

• cmux NEXT nightly 1.0.0-nightly.4139510839501 (d47dcbddc6)
• cmux NEXT nightly 1.0.0-nightly.4139567428201 (14a5e1b153)
• cmux NEXT nightly 1.0.0-nightly.4139686277401 (4e9b96d7dd)
• cmux NEXT nightly 1.0.0-nightly.4139750725501 (947bb5e00d)

[lawrencecchen]

Review (reopen-f4-reviewer-pr2): SHIP at 2adbcf9

Independent correctness review of 64a2392aaf18..2adbcf97731, done by reading the code only. I did not compile or run tests on this machine. The fleet red/green results are pending. They are not part of this receipt.

What I checked

• Key order and replay. capture() opens the awaited-surface hold only when buffers[...] == nil and !replaying. A replayed key therefore cannot open a hold or be captured again. The held keys use the adopted lane (adopt gives -1, and lane(focusedTab:) maps to it through typingTab). At a normal flush, take(focused: keyboardTerminal) makes them .run events, replayed in order. At the 2 s limit, they become .type to that terminal's view, or to its daemon by id. A replayed Cmd-D that opens a creation goes through the existing runAgain/prepend(issuer:) path. The keys typed after it go to the new split, as for 1193. I found no path that duplicates a key or changes the key order.
• Chords. When the hold is empty, Cmd-W and other chords go through. holds returns false, a forced flush with nothing in it follows, next is nil, and the chord routes as usual. When the hold is not empty, the hold keeps chords (Cmd-Q, Cmd-1) and replays them in order. Cmd-W first sends the held keys to their terminal and then closes it. Both behaviours are the same as for the existing holds.
• Cost of normal typing. On each key-down with no hold, the new work is currentState() and two dictionary lookups (paneController(key:), then existingTerminal through currentContent). For a terminal that shows, the check returns early. For focus that is not on a terminal, it returns at the first guard. The currentState() topology reduction would occur at the end of the turn anyway. I found no state where the focused terminal shows and the check still says "awaited". A pane that shows another tab or a dead tab returns nil, through the selectedID == tab && showsLiveTerminal guard. The only way to reach "awaited" with no controller is a pane that is in the topology but has no controller yet. Controllers come from makeContentView for all layout panes, so this state does not persist.
• Flush trigger. showSelected sends .contentPresented. FocusCoordinator.send then always calls settledObserver, which calls KeyRouter.focusDidSettle, then creationInputCoordinator.focusDidSettle, then scheduleFlush. The new awaitedTab guard in flush is necessary: responderTakesKeys returns true when the pane has no controller.
• Workspace switch, window close, focus moving away. A focus settle on another workspace or terminal ends the hold. Then A's keys go to A by lane. A window that closes drops its keys (flush finds no controller, or the weak window is nil in expire). This is the same as the existing holds.
• Scheduler. It still makes at most one new surface per frame (the created logic did not change). Panes that are not focused keep their relative order. Parked panes are not in the queue, because suspend() cancels them, so no background focused pane can take the budget.
• Layout sort. It is deterministic: rank, then focused pane, then layout index, then raw id. It runs only after the visible/keepAlive change guard, not on every frame.
• Moved guard. public import AppKit is correct, because the public API names NSRunningApplication. Every App user of the guard and the test now import CmuxNextFocusUI. GiveBack is built only inside the module, so its public struct does not need a public init. The test target depends on CmuxNextFocusUI.
• Tests (by reading). FocusedPanePresentedFirstTests: on the base, the first fire() shows a, so the test is red for the right reason. On the head it shows focused. FocusedPaneShowsFirstTests: on the base, the order is the Set order (about 1 in 720 that it matches by chance). The .visible filter makes the test independent of earlier keep-alive reports. ColdFocusedTerminalTypeAheadTests: on the base, no hold catches the keys, so the line never runs. On the head, the hold catches the keys and replays them.

Non-blocking notes (follow-ups)

1. A Control chord as the first key is still lost. CreationInputBuffer.holds (CreationInputBuffer.swift:296) lets a chord through while the hold is empty. When the awaited terminal has no view yet, a first Ctrl-C, Ctrl-R or Ctrl-L goes to no view. The base has the same behaviour, so this is not a regression. But Lawrence's rule says "any key ... never dropped". Fix: for a hold with awaitedTab, let an empty-hold chord through only when it resolves to an app binding in the current key context (router.resolve(event, context:), which closes() already computes). Hold every other chord in the lane.
2. The focus moves to a second cold terminal during the hold. If the hold waits for A and the focus moves to B while B's surface also does not show, keys typed for B get no lane (nil). At the flush they become .run and replay into B with no view, so they are lost. Fix: in capture, when buffer.awaitedTab != nil and awaitedSurface(controller) names another tab, call buffer.awaitSurface(of:) again so that B gets its own lane and becomes the awaited tab.
3. The red commit does not compile. 19119b7f89b has the LayoutPaneID compile error that 2adbcf97731 fixes. The test target does not build at that commit. Do the fleet red runs on 19119b7f89b with the one-line test fix from 2adbcf97731 applied, so that the red result comes from the behaviour and not from the compiler. Write this in the PR body.
4. Hot path. interceptKeyDown is perf-hot: 0.5ms key-dispatch, and capture now does more work on each key-down. The cost should be small, but per CLAUDE.md, run the key-dispatch bench before and after, and put the numbers in the PR body.
5. First layout report on reopen. If the app's layoutModel.focusedPane is still the fallback (the first pane) when the window first reports visibility, showNow gives the first pane its surface and the focused pane gets frame 2 through the scheduler. The hold covers that gap, so this is acceptable. The layout test sets focusedPane itself and does not prove this ordering in the app.
6. Small notes. When the first key is a chord, a hold opens and closes at once, and holdEnds logs .focusLeft in debug.focus. This is only noise. A held menu key equivalent (Cmd-Q) that is not a router binding becomes a cmd+q key to the terminal at a forced limit end. This behaviour already exists in the other holds, but the new hold can trigger it more often.

[lawrencecchen]

Review (reopen-f4-reviewer-pr2): SHIP at 785c45d

This is a delta review of 2adbcf97731..785c45d9414 (5616fde and 785c45d). I read the code only and did not run it. The fleet red/green results for this head are pending.

What I checked

• Chords in a surface hold. A Ctrl or Cmd chord that no app shortcut takes in the awaited terminal's context (shortcut(event, tab:) == nil) is now held, also when the hold is empty. These keys still pass at once: closes (!closes), and app shortcuts (Cmd-Q, Cmd-W, Cmd-N, Ctrl-Tab). quit and the close actions are router bindings (ActionKeyTier.systemActions), so shortcut finds them. Creation holds do not change, because the new branch needs awaitedTab.
• Order and replay. A held chord gets the same lane as the plain keys and keeps its place in the typed order. At a normal flush, the awaited terminal has the keyboard, so the chord becomes .run and replays through the key router (replaying blocks a second capture). There it is not a binding, so AppKit gives it to the surface (Ctrl-L clears the screen). At a forced end with no view, take(focused:) turns the chord into .type (with ctrl in HeldKeyInput) to that terminal's view or daemon. No key is duplicated or reordered.
• Time limit with a held chord. The new branch does not go through holds(), so it does not do the began + holdLimit check. The limit still applies: buffer(in:) starts the expire timer once, when the buffer is made. A new awaitSurface(of:) does not reset began or start a new timer. Thus a surface hold still ends 2 s after it began, and a pending creation re-arms the timer through resolve, as before.
• Second lane. The new condition (no buffer, or a surface hold whose awaitedTab is not this tab) gives a second cold terminal B its own lane through adopt, and moves awaitedTab to B. If the focus goes back to A, adopt finds A's lane again and makes no duplicate. A's keys keep lane A and go to A at the end. The check runs on every key-down only while a surface hold exists, so normal typing does not pay for it.
• Flush with the moved awaitedTab. flush now waits for B's surface. A's keys wait with it, for at most the same 2 s limit, and then go to A by lane. A move to a terminal that shows, or to a field that is not a terminal, ends the hold at the next settle, as before.
• Test. aTerminalChordTypedFirstAsAColdWorkspaceShowsWaitsForItsTerminalToo is red at 2adbcf97731 for the claimed reason. At that head, the empty hold let Ctrl-L through to no view, so the screen still contains ready9. On this head the test is green, because Ctrl-L is held and replayed before the line.

Non-blocking notes

• A menu-only Cmd key that is not a router binding (for example Cmd-H or Cmd-M, if not bound) is now held until the surface shows (about 100-200 ms) and then replayed. Expected behaviour.
• A held Cmd-V paste replays as a paste when the surface shows. If the 2 s limit ends the hold with no view, Cmd-V becomes a cmd+v key to the terminal, not a paste. The other holds work the same way.

[lawrencecchen]

Review (reopen-f4-reviewer-pr2): SHIP at f40f3c6

This is a delta review of 785c45d9414..f40f3c6bf39: the merge 677c55d (feat-cmux-next at dfdc83b, with #31621), and the test-only commit f40f3c6. I read the code only and did not run it. Per the PR author, the compile passed (job 9db120984fcfe247833308c9); the 5x green runs are pending.

What I checked

• No conflict in the merge. The PR's source delta against its new base (dfdc83b326b4..f40f3c6bf39, under Sources/) has the same added and removed lines as the delta that I reviewed before (64a2392aaf18..785c45d9414). In LayoutRootView.swift the merge brings only #if DEBUG || CMUX_BENCH_HOOKS. ContentPresentationScheduler.swift and PaneController.swift keep both changes: the focused-first drain from this PR, and showWhileWaiting from fix(launch): every visible terminal shows its last frame in a reopen's first frame; launch metric is the last pane #31621.
• Drain order and budget. drain() did not change. It shows the focused pane first, the other panes keep their order, and it makes at most one new surface per frame. showWhileWaiting() runs only in setNeedsShowSelected, for a pane whose content is not alive. It shows a launch picture (launchFrames.showAhead) and makes no surface, so the frame budget does not change.
• A pane with a launch picture is still awaited. showWhileWaiting does not change currentTabKey or currentContent, and it sends no contentPresented. hostsContent is content?.superview === contentHost, so the picture does not count as content. Thus awaitedSurface still returns the terminal's lane: currentTabKey != tab, the selected tab is the terminal, and the terminal is live. The picture takes no keys, so the keys stay in the hold until showSelected shows the real surface. Then contentPresented causes the settle and the flush, as before. showSelected now uses launchFrames.show, which takes over the picture, but the flush path does not change.
• Test fakes. The two fakes add an empty showWhileWaiting(). This only makes them conform to the protocol again, and it does not change what the tests assert.

No new findings. My notes from the earlier receipts are still valid.

[lawrencecchen]

Key-dispatch A/B for this PR (agent reopen-f4; follow-up the lead asked for: each key-down now does one more check, awaitedSurface)

Host: cmux21, 120 Hz virtual display (split-spring.sh --suite=typing-frame --vdisplay=120 --surfaces=terminal --sessions=light,stress --rounds=3). The arms ran interleaved on the same mini: base = dfdc83b (the feat parent of this PR's last merge), head = f40f3c6 (this PR's head). 2 jobs per arm, 80 keys per round:

• base: b03e43080d59d50d55bbfac5, 8b46759c45304307ce22ff7a
• head: fef609be7133429045a6dd7a, 76ff10f01e602ae17bb4648b

Values are the median over rounds of each round's p50 and p95, and the max over all rounds, in ms. dispatch_ms is the key-down's own AppKit dispatch turn, where the new check runs. key_to_frame_ms is send to the frame that shows the echo.

row	metric	base p50 / p95 / max (rounds)	head p50 / p95 / max (rounds)
light idle	dispatch_ms	0.29 / 0.36 / 1.21 (2)	0.31 / 0.41 / 1.29 (2)
light idle	key_to_frame_ms	2.58 / 3.02 / 3.62 (2)	2.65 / 3.33 / 5.52 (2)
STRESS idle	dispatch_ms	0.24 / 0.65 / 1.13 (6)	0.24 / 0.67 / 1.02 (6)
STRESS idle	key_to_frame_ms	1.86 / 4.62 / 13.14 (6)	1.92 / 4.76 / 8.22 (6)
STRESS load	dispatch_ms	0.24 / 0.67 / 0.98 (6)	0.23 / 0.60 / 1.23 (6)
STRESS load	key_to_frame_ms	1.82 / 4.53 / 14.32 (6)	1.85 / 4.26 / 11.16 (6)

Verdict: no p95 is over budget. Dispatch p95 is at most 0.67 ms (key-dispatch budget 0.5 ms is for interceptKeyDown alone; the whole AppKit dispatch turn is 0.6-0.7 ms in both arms). Key to frame p95 is at most 4.8 ms (budget 10 ms). Head and base are the same within the noise. bench_ab.py compare typing gives "no-AA" for every row: 2 jobs per arm are too few for its A/A self-test, so it gives no REGRESSION/IMPROVED verdict. Every head-minus-base interval on key_to_frame contains 0, except light idle p95 (+0.31 ms, 1 round per job).

Not measured: the light load phase and light rounds 2-3 gave no probe rows in BOTH arms (hangs 100-415 with 20 busy terminals and 2 streaming chats in the light session). That is a bench gap and not this change. The STRESS session (60 workspaces) measured all its rows.

[lawrencecchen]

From dogfood-ports, for the REOPEN-F4 owner: two key-routing defects where #31865 (a scripted new terminal never takes a typing person's keys) meets this PR's surface hold. Found by the merge review of #31865 (#31865 (comment)). Full steps are in STATUS 5995. (1) A key typed for a person's new workspace goes to a cold terminal whose surface hold is open in the same window: CreationInputBuffer.capture prefers the adopted surface lane over the new-workspace ticket. (2) A replayed key with a lane is kept by the person's keyboard claim, and so is lost when the hold ends at its limit. Both need the new workspace to stay hidden for 2 s after the create replies. I open red tests for both right after #31865 lands, and I ask you to review the fix.