[lawrencecchen]

Summary

P0 1193 (tip watcher smoke on feat 5097a27, granted mini cmux18, step 23 failed in 2 of 3 rounds): Cmd-D, then a line typed at once, then Cmd-D again, then a line typed at once. Both lines ran in the FIRST new terminal. The second new terminal got its shell but no line and no focus. The pane widths in the round's check-05.png show that the pane with both lines is the first new pane (the second Cmd-D split it).

Cause: CreationInputBuffer.takesKeysEarly(tab:) was true for the early tab of ANY pending creation. After the second Cmd-D, the focus still named the first creation's early view until the second creation's focus landed. The first creation was also still pending, because its reply is slower under load and the second create waits for it in the workspace's create chain. So CreationInputCoordinator.capture let the second line's keys, and the keys held before them, go to the first terminal.

Fix: each held key gets a lane when it is typed. The lane is the creation whose tab the focus named, or was on its way to, at that time (FocusState.typingTab).

• An early view takes only its own lane's keys, and only when its terminal view is the window's first responder (TerminalSession.hasKeyboard). A key typed for another creation waits for that creation's terminal.
• At the hold's end, every held key runs in typing order (CreationInputBuffer.HeldKey):
  • Keys of a lane whose terminal is not the focused one are typed by THAT terminal (.type): by its view's own Ghostty key encoder (TerminalSurfaceView.typeHeldKey: modifiers, Option-as-Alt, cursor and keypad modes, Kitty protocol; no input method), also while that view is hidden (another workspace, an unselected tab: the content cache keeps it). When the terminal has no view at all (evicted from the cache, or another machine's), the daemon types them with that terminal's own modes (send-key / send, HeldKeyInput, as a TUI's Command chords already go), on the machine its creation was on; an Option key follows Ghostty's macos-option-as-alt (true, left, right) as the view's encoder does (GhosttyRuntime.optionAsAltValue: ESC and the base key). Only a closed terminal takes its keys with it, as a closed creation already does. A held Ctrl-C never reaches another terminal's process.
  • A Command chord of such a lane (.command) that is an app shortcut runs with that terminal's tab as its target (RegistryKeyBindings.run(_:keyContext:target:)) and with that terminal's key context, as a key press there would; the handlers resolve a tab target to its pane (AppActionContext.paneController, daemonPane). So a held Cmd-D splits the pane it was typed for, never the focused one. A Command chord that is no app shortcut is that terminal's key (a TUI's Cmd keys). An action whose descriptor declares no target kind (New Window, the palette) is app- or window-level and ignores the target.
  • Cmd-W (any close key) is never held: it acts at once on what it closes, and a close of a pending creation drops the keys typed for it (CreationInputBuffer.holds, unchanged). cmdWTypedForAPendingSplitClosesThatSplitOnly guards that rule in the sequence Cmd-D, keys, Cmd-W, Cmd-D.
  • The focused lane's keys and keys of no lane run again as typed, as before (input methods still see them).
• Nothing is delayed or blocked that was not before, and the smoke gate's typing does not change. Keys are dropped (logged) only for a closed terminal, as before, and in two rare cases noted under Follow-ups.

The perf line's rule (050651b: only the newest pending creation's early tab takes keys) is not ported as is. It sends keys held for the first creation to the second terminal when the second gets the keyboard first.

responderTakesKeys (any non-terminal first responder takes the keys) stays only for the final flush, after every creation replied and the focus it asked for landed. There, the focused view is the one the creation asked for (for example, a New Tab page from a split of a page tab), and only the keys of the focused lane or of no lane go to it. The early path no longer uses it.

Test seam (DEBUG and bench builds only, a release router drops debug.*): debug.creation.hold {n} / debug.creation.release {n} (DebugCreationHold, one per DaemonService, wired in intendNowReporting) hold the n-th creation's daemon reply until released (bound 30 s; the release answers resumed, the creations it really let go). stand_in: [n] also keeps creation n's stand-in out of the store until its release, so its focus is asked for and cannot land: the state of a window whose main thread ran the next keys before it laid the new pane out (TIP RED 1193 under the hog), made on purpose. Without it, the reply hold alone does not fail the base: pa-d's first rounds passed on the red ref, because creation 2's focus landed within a frame, so the smoke journey makes the 1193 race in every round on any host with no hog (cmux-ad 11:25Z). No product timing changes.

CreationHoldLog moves to CmuxNextFocusUI (beside feat's CreationHoldEnd), and DecidedKeyEvents (pure AppKit, the key router's) to CmuxNextFocusUI, so CmuxNextApp shrinks.
Owners told through this PR: PL-typing (TerminalSurfaceView+Keyboard.swift: the new typeHeldKey, no change to keyDown), PL-ghostty (TerminalSession.hasKeyboard).

Combined stack (lead 03:50Z)

The merge service lands only PRs based on feat-cmux-next, so the reviewed follow-ups are merged into this branch with plain merges (no force push). Each part was reviewed at its own head:

• fix(app): held Control shortcuts, replays and hold ends deliver each key to its own terminal (P0 1193 follow-up) #29693 at bc84781 (SHIP): held Control shortcuts, replays and hold ends deliver each key to its own terminal (fixes Follow-ups 1 to 3 below).
• fix(app): held keys for one terminal go out through one ordered send queue (P0 1193) #29919 at ded9410 (SHIP): held keys for one terminal go out through one ordered send queue (DaemonService.sendInOrder).
• fix(app): closing a replay-opened split keeps the line carried for another terminal (P0 1193) #29922 at d0ec8fa (SHIP): closing a replay-opened split keeps the line carried for another terminal.

Merge of feat 1d10c48 (0704e13): feat's #28810 added the same replay seam as this PR (HeldKeyReplay, injected through AppServices/KeyRouter) and moved CreationHoldEnd to CmuxNextFocusUI. The merge keeps feat's seam (this PR's runKey is gone; the tests pass their replay through PinnedPageTests.withApp(heldKeyReplay:)), keeps one CreationHoldEnd (feat's), and puts CreationHoldLog beside it in CmuxNextFocusUI. Head: 1d942e4.

Testing

Red-first: SecondCreationKeysTests (CmuxNextAppTests, real same-tree daemon). The red ref is branch fix/p0-1193-key-lanes-red at 6f698ae: base sources, plus only two test seams (the replay seam CreationInputCoordinator.runKey and the DEBUG debug.creation.hold hook), plus these tests. The seam is behavior-neutral: its default is { event, _ in NSApp.sendEvent(event) }, the exact call it replaces at the two replay sites, and only a test assigns it (a test window is never key, so NSApp.sendEvent cannot deliver a replayed key there). (The first red commit 0383621 did not compile: a nested #require and await in #expect messages; fixed.)

1. keysTypedAfterTheSecondCreationBeganNeverGoToTheFirstTerminal: the smoke's step 23.
2. keysHeldForTheFirstCreationNeverGoToTheSecondTerminal: the other direction (the case the perf rule gets wrong).
3. heldControlAndArrowKeysReachOnlyTheirOwnTerminal: byte readers in both terminals: a held Ctrl-C and Up reach the first terminal as 03 and cursor-up, nothing reaches the second.
4. eachHeldKeyRunsAtItsPlaceInItsOwnTerminal: Cmd-D, "ls", Up, Ctrl-C, Cmd-D, a line, all held: the first terminal gets 6c 73, cursor-up, 03 in order; the held Cmd-D splits the FIRST terminal's pane (the new pane lies between the first and the second), at its place; the line after it runs in that new pane; nothing reaches the focused terminal.
5. heldKeysReachTheirTerminalAfterItsWorkspaceWasSwitchedAway: Cmd-N before the hold ends; the held line still runs in the first terminal.
6. HeldKeyInputTests: the daemon path's key mapping (option-as-alt per setting and Option side, the config read, the order of text, Up, Ctrl-C, Return). It needs the new API, so it is committed with its fix and has no red run.
7. cmdWTypedForAPendingSplitClosesThatSplitOnly: Cmd-D, keys, Cmd-W, Cmd-D in one turn: Cmd-W closes only the first split, the original pane stays, the keys reach no terminal. Expected green on the base too (it guards the existing close rule).

Fleet evidence (filled in as the jobs end):

• Compile: head 201b1e4 job ef1700ef9b254b4b1c3be223 PASSED; red ref 6f698ae job 7c96de5abb1ec85241a977fb PASSED (app, CmuxNext with its tests, cmux-tui). (Earlier: 2c7852b3, a49e899a and 9b64e3fb failed in test or seam files only, fixed.)
• Red: VALID. Display step 56c5ebbc823d3997348eada3 at the red ref 6f698ae (base code + test seams; gui-session-v1, "gui-session-v1 step in cmux's console session (launchctl asuser 501)", CMUX_TEST_REQUIRE_GUI=1), SecondCreationKeysTests: 5 of 6 fail, each FIRST on its outcome check: "the line typed for the second terminal ran in the first one" (step 23); "the line held for the first terminal ran in the second one"; "a key held for the first terminal reached the second one" (Ctrl-C, Up); "a key held for another terminal reached the focused one" and "the held Cmd-D split another pane than the first terminal's" (x 435 / new 875 / second 655); "the line held for the first terminal was lost when its workspace was switched away". The Cmd-W guard cmdWTypedForAPendingSplitClosesThatSplitOnly PASSES on the base, as a regression guard should. (Earlier runs 5e829f0c5c0ff1f0d9702c6a and f78bf3a645e937c0a98ffb98 failed for test reasons and do not count.)
• Green: VALID. Display step e080cd4890f129a360c93ac8 at the head 201b1e4 (console session, CMUX_TEST_REQUIRE_GUI=1): SecondCreationKeysTests 6 of 6 passed, HeldKeyInputTests 3 of 3 passed; no skip, no FLAKY notice.
• On-screen evidence (cmux-ad 11:05Z bar met): pa-d's journey tipred-1193-stand-in (cp/pa-d-dogfood-smoke-gate c6358ca, its own review SHIP at that sha), cmux18 whole host, no memory hog, debug.creation.hold {"n": [1], "stand_in": [2]}. Per round: python3 scripts/journeys/run.py --build JOB --journey tipred-1193-stand-in --exclusive --whole-host --hosts cmux18.

Build	Debug job	Result
red ref ddb6037 (base code + test seams)	9c32e47752065f44d97a857b	FAIL 5/5
feat 5097a27 (the TIP RED tip) + the hook commits, cb31520	1ac13c76efd73899c7bfee00	FAIL 5/5
head f260f8e (the same app code as this PR's head)	741ca0d01ac4bd81d539fb1e	PASS 5/5

Every round of all three is the race: the release reply {started: 2, resumed: [1], shown: [2]}, the second Cmd-D "dispatcher: run(splitRight)". Each red: d1 and d2 both in the first new pane's terminal, the focus on the second new pane with no line (TIP RED 1193). Each head pass: each line in its own new pane, hold path true. Data: /work/tmp/pa-d-tipred-1193/v7-standin/{red-,f5097-,head-*}/tipred-1193-stand-in/result.json. Not run: hog rounds on the head.

Observed / Not run

Observed: the smoke round's captures (round-01 and round-02 check-05.png, debug.key replies) and the code paths named above. prepush-gate.py: no new violations.
Combined head 1d942e4 (P0 proof at the exact head):

• Compile f67ff56f88ef04dff4864286: PASSED (CmuxNext with its tests, app, cmux-tui).
• Display proof 2c0b0cec11d203e43ecc014e (cmux12s, console session, CMUX_TEST_REQUIRE_GUI=1, same-tree cmux-tui fetched): all 7 suite runs passed, none skipped. OrderedSendReleaseTests 1/1; SecondCreationKeysTests 11/11 in each of 3 runs; HeldKeyInputTests 3/3; CreationInputHoldTests 6/6; SplitOfPendingSplitTests 3/3 (its one known issue is feat's intended check that a replay that drops the keys fails).
• Not counted: 7b3f3105afedb6195b06f5bf on the same head failed for infrastructure (the worker's same-tree cmux-tui build failed at the ghostty-next fetch, "shallow file has changed"), so its daemon suites were skipped.
  Nothing was built or run locally.

Follow-ups (review receipt, low; fixed by #29693, now merged into this branch)

1. A held Control chord that is an app shortcut (Ctrl-, Ctrl-Tab, Ctrl-1..9) for a terminal that is not focused is typed into that terminal, not run as the shortcut: only Command chords go through app dispatch (CreationInputBuffer.take(focused:)`).
2. When a replayed key opens a new creation, prepend gives the remaining keys the new creation's lane; with mixed lanes (a creation started by a click) a key held for another terminal can go to the new split.
3. A held key's daemon path uses the window's daemon, not the pane's: for an evicted view of another machine's split, the keys are dropped (logged).

Performance

No perf numbers: this is a correctness fix (keys typed while two creations are pending reach the terminal they were typed for). It adds no work on the key path when no creation hold is open (capture returns at its first guard, as before), and it moves no work onto the main thread. perf claim: none.

Changelog

Fixed: Lines and shortcuts typed while new panes open run in the pane they were typed for, in the order they were typed, also when that pane is hidden or closed early

Proof

No capture: key routing between terminals; the evidence is the fleet tests and the smoke journey above.

[github-actions]

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

Review 1d942e4: 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=pr29301 -f ref=fix/p0-1193-key-lanes -f platform=macos -f backend_mode=local

red: cmux-next checks (god files, concurrency, crash safety, l10n); no finished base run on 1d10c48 to compare; do not merge until green; see lane-rules

Default changes

This pull request changes 1 default at 1d942e4397f4 (what everyone gets without configuring anything):

• tunable-source.CmuxNextApp/Handlers/PaneHandlers.swift:split: "1b5e985ae601a3fe5f6b4cdb49656b109e88848b008a39a15d18927adde5d4bc" -> "6caa1abde07114b35831d6c3545002389d9fff5995b24a33b9ebee6fff49134e"

Signed off on this commit by review (independent review subagent).

Merge receipt: merged as 373f34634dc0 with these defaults changed, signed off by review (independent review subagent).

Regenerate the snapshot with python3 scripts/ci/defaults_guard.py snapshot.

Shipped in:

• cmux NEXT nightly 1.0.0-nightly.4130052256501 (28aa638015)

[cursor]

Bugbot needs on-demand usage enabled

Bugbot uses usage-based billing for this team and requires on-demand usage to be enabled.

A team admin can enable on-demand usage in the Cursor dashboard.

[lawrencecchen]

Review (independent review subagent): SHIP at 1d942e4
reviewer-session: 29374706-521f-422b-97c6-4a8f53a6c0c7
author-session: a728800f37f9342b9
R9: pass
perf claim: none

Verdict: SHIP (merge resolutions correct; the fleet compile and display proof were not finished when I reviewed)

#29301 now combines the reviewed stack into one PR on feat-cmux-next with three plain merges. Each part had a SHIP receipt:

• 2f0ffb6: SHIP
• bc84781 (fix(app): held Control shortcuts, replays and hold ends deliver each key to its own terminal (P0 1193 follow-up) #29693): SHIP
• ded9410 (fix(app): held keys for one terminal go out through one ordered send queue (P0 1193) #29919): SHIP
• d0ec8fa (fix(app): closing a replay-opened split keeps the line carried for another terminal (P0 1193) #29922): SHIP

I reviewed the full diff git diff origin/feat-cmux-next...1d942e4397f (20 files, +1245/-72). I also reviewed each merge with git show --remerge-diff, which shows only the conflict resolutions and the changes a clean merge did not make. The merge base is 1d10c48. Between that base and the feat-cmux-next tip (d0fce7f), nothing changed in CmuxNextFocus, CmuxNextFocusUI or DecidedKeyEvents.

Merge 0704e13 (feat 1d10c48 into 33cee3e)

• Replay seam: feat test(split): #28436 was the test window, not the key path: type after the hold, and cover typing during it #28810 already added replay, so the resolution keeps it and removes the PR's runKey. .run now calls if let router { replay(event, window, router) }. With no test override, the app still replays through NSApp.sendEvent:

  • AppDelegate.swift:127 passes heldKeyReplay: { event, _, _ in NSApp.sendEvent(event) }.
  • The KeyRouter.init default is the same.
  • KeyRouter.creationInputCoordinator gives it to CreationInputCoordinator(router:replay:).
  • The PR's old runKey default was also NSApp.sendEvent, so the app does not change.

• No duplicate type: CreationHoldEnd is now only in CmuxNextFocusUI/CreationHoldEnd.swift (feat's copy). The deleted CmuxNextFocus copy had the same five cases, including creationFailed. CreationHoldLog moved to CmuxNextFocusUI, next to the enum. It needs no other module (CmuxNextFocusUI depends on Actions, Design and Signposts). No other source or test refers to the old location or to the removed lastHoldEnd/failedCreation stored properties. Tests use lastHoldEnd(in:), which stays.

• Feat behavior kept: feat's failed-creation tracking (failedCreation, .creationFailed on an unforced end, .windowClosed when the window is gone) is now in CreationHoldLog, with the same logic:

  • resolve(landed: false) calls creationFailed(in:).
  • The window-gone path calls windowClosed.
  • end(in:forced:) = forced ?? (failed ? .creationFailed : .focusLanded).

  Feat's "a replayed key opened a new hold: the rest wait for it, in order" behavior is in runAgain: next !== buffer || openedCount changed leads to prepend(..., issuer:). In flush, the old buffer has already been removed, so any new buffer matches the next !== buffer check.

• PR behavior kept: lanes, .type/.command, the early-lane path, typingTab and machine: on begin are all present in the resolved coordinator.

• Imports: the coordinator imports CmuxNextFocus (for FocusState.typingTab) and CmuxNextFocusUI. KeyRouter already imports both.

• SecondCreationKeysTests: it passes its window replay through PinnedPageTests.withApp(heldKeyReplay:) instead of setting runKey. The replay is the same as before (key router, then window.sendEvent).

Feat tests that use the seam (SplitOfPendingSplitTests)

I checked that the PR's lane routing does not change what these tests prove:

• In the "typed during the hold" test, the keys are typed after the second Cmd-D. At that time the focus expectation names the second split's tab, so they get that split's lane.
• At the hold's end the focus is on that tab, so they are .run keys, and they go through replay.
• The split's public tab id is minted by the client, and the daemon's pane keeps it (ProvisionalPane.tabID). Thus the lane tab and the focused tab match after the split is confirmed.
• So the positive test still runs the line in the second pane. The "drop" test (replay: { _, _, _ in }) still fails on its own assertion inside withKnownIssue.
• The display proof 7b3f3105afedb6195b06f5bf includes SplitOfPendingSplitTests, so it will confirm this.

Merge b22ba9f (#29919 ded9410)

One conflict, resolved as case .run(let event, _): if let router { replay(event, window, router) }. This combines #29919's HeldKey.run(_, lane:) shape with feat's seam. All other #29919 content merged without conflict: sendInOrder, the strong capture, and OrderedSendReleaseTests.

Merge 1d942e4 (#29922 d0ec8fa)

No conflict, and --remerge-diff shows nothing. The change in CreationInputBuffer.cancel and its test closingAReplayOpenedSplitKeepsTheLineCarriedForAnotherTerminal are present.

Evidence state at review time (read-only cmux-ci status)

• Compile f67ff56f88ef04dff4864286 (cmux-next-swift-check ... --package CmuxNext --app at 1d942e4): running.
• Display proof 7b3f3105afedb6195b06f5bf (OrderedSendReleaseTests, SecondCreationKeysTests x3, HeldKeyInputTests, CreationInputHoldTests, SplitOfPendingSplitTests at 1d942e4): queued.
• This SHIP covers source correctness. The author must see both jobs green at this exact head before ready-to-land. A compile error or a red in these suites cancels this receipt.

Not blocking (carried from the earlier reviews)

Other writers to the same terminal are still unordered against sendInOrder:

• the view's TerminalAttachment path,
• TerminalSession.sendBytes,
• the TerminalHooks send-key.

They were unordered before this PR too, and they need a live view. I recommend a follow-up.

Not run by me: no build or test run.