[lawrencecchen]

Summary

#32098 has landed; this branch is merged with feat (da9e2e6).

Lost keys (review of #32098, finding 1, #32098 (comment)). The steps:

1. The person asks for a new workspace W. A creation hold and the person's keyboard claim open.
2. The person clicks the pane that already has the focus.

The click ends the claim (personActed from the app's one mouse-down subscription), but it moves no focus generation: the responder does not change, and cmux-focus-core's is_noop_responder returns before the generation bump. So the keys typed after the click still took W's lane through buffer.newestGeneration == generation, and they were dropped when W never showed.

After this change, when the person's action ends their claim, the window's hold records that they moved on from its new workspaces (CreationInputBuffer.personMovedOn()). The generation that kept the lane is cleared. A key typed now passes on to the focused view at once when all three of these hold:

• every creation of the hold is such a workspace;
• the key is for no creation's or surface's terminal;
• no key that runs as typed waits before it, so the order is kept.

Keys typed before the click still wait for W. The rule is in CmuxNextFocusUI. cmux-focus-core is not changed (it is an FFI input). CmuxNextApp lines: +0.

REOPEN-F4 owner (a02ba201): please look; this is the creation hold next to your #31707 surface hold.

Testing

Focused command (fleet, Mac): package-test-lane.sh suite Packages/macOS/CmuxNext PersonTerminalKeyboardClaimTests.

• Red at 36fc468 (test only): step 983083ace1014a807c8de4b6 (aws-m4pro-7) FAILED as expected. keysTypedAfterAClickOnTheFocusedPaneReachThatPane: the keys typed after the click were lost (delivered == []), and the window still kept the keyboard for the creation.
• Green at dbc308d: step f96929d4fe44ed3eb9985185 (aws-m4pro-8) PASSED all 22 suites. PersonTerminalKeyboardClaimTests, HomePendingTerminalFocusTests, CreationInputHoldTests and SecondCreationKeysTests passed 5 of 5 each; ColdFocusedTerminalTypeAheadTests and CloseThenTypeKeysTests passed once.
• Compile-check of the head and of the red ref: passed.

Review FIX repair (comment 6575210178)

Two lost-key blockers, each with a red test first (red ref c800f7d):

1. passesOn skipped the fix(focus): a reopened window's focused terminal is presented first, and keys typed before its surface wait for it (REOPEN-F4) #31707 surface hold. A cold terminal that the person clicked to, with the left workspace's hold still open, got no surface lane, so a line typed at once reached no terminal view. Fix: a hold whose every creation the person left (personLeftEveryCreation) takes the focused terminal's surface lane as no hold would. A key passes on only while responderTakesKeys holds, and no fix(focus): the reopen key hold also waits for a restored browser tab's page; Cmd-L reaches its address bar (REOPEN-F4 browser case) #32030 page is awaited (!awaitsPage; fix(focus): the reopen key hold also waits for a restored browser tab's page; Cmd-L reaches its address bar (REOPEN-F4 browser case) #32030 landed while this was open and is merged in).
2. A creation asked for after the click (Cmd-T's non-optimistic path) got the left workspace's lane (workspaceTickets.max()), and its keys were dropped. Fix: workspaceTickets.subtracting(movedOnFrom).max().

• Red: step 8d96ff3b52dd1be6c1e75375 (aws-m4pro-1) FAILED as expected:
  • ColdFocusedTerminalTypeAheadTests.aLineTypedAsAColdWorkspaceShowsAfterTheClickThatLeftANewWorkspaceReachesItsTerminal: the line never ran in the cold terminal.
  • PersonTerminalKeyboardClaimTests.keysTypedForACreationAfterTheClickNeverGoToTheLeftWorkspace: replayed == [].
• Green before the feat merge: step 5b569ed981016270a1a67fc5 passed 27 suites.
• Green at the merged head da9e2e6: step 9fc08cbe3665e6a74faef995 (aws-m4pro-9) passed all 27 suites. PersonTerminalKeyboardClaimTests, ColdFocusedTerminalTypeAheadTests, HomePendingTerminalFocusTests, CreationInputHoldTests and SecondCreationKeysTests passed 5 of 5 each, plus CloseThenTypeKeysTests and FocusedPanePresentedFirstTests. The compile passed.

Observed / Not run

Observed: the fleet steps above. Not run: a live click in a tagged build; a click that moves the focus (that path already bumps the generation and is covered by aPersonsFocusMoveEndsTheClaim).

Changelog

Fixed: Keys typed after a click on the focused pane, while a new workspace opens, reach that pane and are no longer lost.

Proof

No capture: key routing only.

[github-actions]

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

Review da9e2e6: 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=pr32148 -f ref=fix/creation-claim-ended-by-click -f platform=macos -f backend_mode=local

web and size checks: green

Shipped in:

• cmux NEXT nightly 1.0.0-nightly.4144668469201 (91cf7c0aa8)
• cmux NEXT nightly 1.0.0-nightly.4144754641401 (f2a2b6d444)
• cmux NEXT nightly 1.0.0-nightly.4144882653901 (612c99d3c9)
• cmux NEXT nightly 1.0.0-nightly.4144971038501 (5f937c4fc4)
• cmux NEXT nightly 1.0.0-nightly.4145066734501 (6fdfe98ecd)
• cmux NEXT nightly 1.0.0-nightly.4145248477801 (7bfeec05fd)
• cmux NEXT nightly 1.0.0-nightly.4145363708701 (c81ea581fe)

[lawrencecchen]

Review (subagent, correctness first): FIX at dbc308d

I read the diff of 36fc468 and dbc308d and the full files at the head. I ran no build or test. The fix is right for the case it tests: the person clicks the focused pane, the claim ends, personMovedOn() clears newestGeneration, and passesOn lets the keys after the click go to that pane while the keys typed before it keep the workspace lane. I found two paths where a key typed after the click is still lost.

Blockers

1. passesOn skips the fix(focus): a reopened window's focused terminal is presented first, and keys typed before its surface wait for it (REOPEN-F4) #31707 surface hold, so a key can go to a pane that has no surface yet (REOPEN-F4 comes back).
   CreationInputCoordinator.swift:216 adds a surface lane only when no buffer exists, or when the buffer already waits for a surface (buffers[n].map { $0.awaitedTab != nil } ?? true). When the moved-on workspace buffer is still there, no surface lane is added. lane(focusedTab:) is then nil, and passesOn (CreationInputBuffer.swift:201-204, called at CreationInputCoordinator.swift:225) returns true. The key goes on to the window with no check of awaitedSurface or responderTakesKeys.
   Repro: ask for a new workspace. Within its reply plus holdLimit (after the reply the buffer stays while awaitedWorkspace != shown, up to 2 s), click another workspace in the sidebar (ActionRouting+SidebarUserIntent → personActed → personMovedOn). It shows cold, and you type at once. The first keys reach no terminal view.
   Before this PR, those keys were held (lane nil once the claim ended), and the flush waited for responderTakesKeys, which is false while the selected surface is still to come. So this is a regression.
   Fix: pass on only when nothing waits for content, for example if kind == .content, let controller, Self.awaitedSurface(controller) == nil, Self.responderTakesKeys(controller, window: shell), buffer.passesOn(...). Or let the line-216 surface check also run for a buffer whose creations are all moved-on. awaitedSurface is already the per-key check when no buffer exists, so the cost is the same. fix(focus): the reopen key hold also waits for a restored browser tab's page; Cmd-L reaches its address bar (REOPEN-F4 browser case) #32030's page hold (awaitsPage, no lane) needs the same guard once it lands: as it is, passesOn would also let the first key reach a page that does not exist yet.

2. A creation started after the click takes the moved-on workspace's lane, and its keys are dropped.
   personMovedOn() records movedOnFrom and clears newestGeneration, but capture still picks workspaceTickets.max() (CreationInputBuffer.swift:246), and that set still holds the moved-on ticket.
   Repro: after the click, press Cmd-T. It now passes, which is new in this PR. The non-optimistic path is PaneController+Intents.swift:147, begin(in:generation:) with no tab:. That open() sets newestGeneration to the new intent again, so forNewWorkspace is true at CreationInputCoordinator.swift:224. passesOn is false (movedOnFrom.count is 1, nextID is 2), and lane(focusedTab:) is nil (no laneTabs entry for the new tab). The next keys are captured with creation = 1, the moved-on workspace.
   The new tab's intent replaces the workspace's expectation, so the workspace never shows. The forced flush's dropKeys(ofWorkspacesOtherThan:) (CreationInputCoordinator.swift:382) then drops the keys typed for the new tab.
   Fix: let workspace = forNewWorkspace ? workspaceTickets.subtracting(movedOnFrom).max() : nil. A regression test should do click, then a second creation with no tab lane, then keys, then the workspace never shows, and expect the keys in the new tab.

Checked, no finding

• Order before and after the click: the keys typed before the click keep lane 1 (dropped if the workspace never shows, as designed, or bound to its terminal by bindNewWorkspaceKeys). A key that runs as typed and still waits (creation == nil) makes passesOn false, so later keys queue behind it in order. A hold that also has a split, a close or an adopted lane (movedOnFrom.count != nextID, or lane != nil) keeps holding as before.
• A pending terminal's own keys: positive lanes still win in capture, and earlyLane is not affected.
• Hold limit: passesOn is checked before holds, so a pending creation no longer keeps the keys typed after the click. The expire and forced-flush paths do not change. If the create fails before the click, personMovedOn returns early (workspaceTickets is empty), and the buffer flushes on the failed reply, so nothing is lost.
• fix(focus): a reopened window's focused terminal is presented first, and keys typed before its surface wait for it (REOPEN-F4) #31707 surface hold with a lane: when an adopted lane names the focused tab, lane(focusedTab:) is non-nil, so passesOn is false and the key keeps its surface lane (forNewWorkspace is now false, so capture no longer gives it to the workspace). Blocker 1 is the case where no lane was added.
• Test determinism: the assertions on b and c come from synchronous interceptKeyDown returns. until is a polled condition with a 20 s deadline, and either flush path (on the failed reply, or the 100 ms limit) gives the same delivered. The result does not depend on timing. (The harness's Task.sleep polling was there before this PR.) The test covers only a failed workspace with a no-op click. It covers neither a workspace that lands nor a second creation.
• Main-thread cost per key: passesOn is O(lanes in the hold + held keys) and runs only while a buffer exists. It does no O(session) walk, no I/O and no wait, so it is well inside the 10 ms budget. The guard from Blocker 1 adds the same awaitedSurface check the no-buffer path already runs on each key.

[lawrencecchen]

Review (review-32148-correctness): SHIP at da9e2e6

Correctness review of the full head (CreationInputBuffer, CreationInputCoordinator, CreationKeyboardClaims, both test files), read in a worktree at da9e2e6. No compile or test run by me; I read the fleet logs.

Summary:

• Both prior blockers are fixed. (1) With every creation left, capture now opens the fix(focus): a reopened window's focused terminal is presented first, and keys typed before its surface wait for it (REOPEN-F4) #31707 surface hold for a cold focused terminal (line 219), so the key gets the adopted lane and passesOn returns false; responderTakesKeys is a second guard. (2) workspaceTickets.subtracting(movedOnFrom).max() keeps a later creation's keys out of the left workspace's lane.
• Lost keys: none found. A key passes on only with no lane for the focused tab, no fix(focus): the reopen key hold also waits for a restored browser tab's page; Cmd-L reaches its address bar (REOPEN-F4 browser case) #32030 page awaited, no nil-lane key waiting before it (order), and a responder that takes keys. A close, split or new tab after the click opens a ticket, so personLeftEveryCreation goes false and the old rules apply.
• Held forever: no. The PR adds no new hold lifetime. A surface await opened inside an existing hold ends with that hold's expire task (armed at creation and at each reply), or at the request timeout while a reply is pending, as before. When the window closes, flush drops the buffer as before.
• movedOnFrom is bounded: it is a subset of the ticket ids 1...nextID of one buffer, formUnion is idempotent, and the buffer is released when the hold ends.
• Main thread: the new checks are O(held keys + lanes) per key, with no blocking.
• Evidence matches the description. Red step 8d96ff3b52dd1be6c1e75375 at c800f7d: the cold-terminal test failed (line never ran), and keysTypedForACreationAfterTheClickNeverGoToTheLeftWorkspace failed (replayed == []). Green step 9fc08cbe3665e6a74faef995 at the head: 27/27 suites passed, and each of the 3 new tests passed 5/5.

Non-blocking notes (not regressions, base behavior):

1. awaitedWorkspace still names a workspace the person left. When it replied and never shows, the hold (cold-terminal lane keys, nil-lane keys, and a later Cmd-T's keys) ends only at holdLimit (2 s after the last reply). These keys are delayed, not lost. If you skip left tickets there, you must decide what happens to the keys typed for W before the click.
2. If one workspace ticket of the hold failed before the click, it is not in workspaceTickets, so movedOnFrom.count != nextID and passesOn never holds for that buffer. The keys typed after the click then wait as nil-lane keys and run as typed at the end of the hold. If a second workspace then shows, they go into it. This needs a narrow sequence (two new workspaces in one hold, one fails, then a click).
3. personMovedOn runs only when personActed ends the claim. A claim that ends in holds() (the person's focus-move count changed) does not mark the tickets as left. I found no person path that does not call personActed first (mouse-down observer, willRun for .user), so this note is only about robustness.

[blacksmith-sh]

Found 1 test failure on Blacksmith runners:

Failure

Test	View Logs
test_the_nightly_is_covered (main.NightlyStepCoverageTests.test_the_nightly_is_cove red)/ test_the_nightly_is_covered (main.NightlyStepCoverageTests.test_the_nightly_is_cove red)	View Logs

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