spawn focus-steal: human keystrokes corrupt launcher line, spawn wedges until manual Enter

[EtanHey]

What happened (Etan, live, 2026-08-17 ~22:10)

brainlayerClaude spawned a cursor worker while Etan was typing. The new pane stole focus mid-keystroke; his characters ("ng") landed in the fresh shell before the launcher command. Terminal record:

Last login: Mon Aug 17 22:10:32 on ttys000
ng %
etanheyman ~  $
etanheyman ~  $ brainlayerCursor -s
[4] 55084

The launcher line sat unsubmitted until Etan manually pressed Enter. Until then the pane never registered as initiated for the fleet. He reports this is recurring and recent ("wasn't the case that much in the past").

Mechanism (from source)

1. agent-engine.ts:6834-6847 — spawn MUST focusSurface the new pane before any I/O ("a tab created in an unfocused pane does not initialize its terminal"). This is the focus-steal window: any human keystrokes in flight land in the new shell.
2. server.ts sendLauncherCommandToSurface waits for shell-ready, then types the command and Return as terminal input into the focused pane.
3. The recovery path submitPendingLauncherCommand only presses Return when screenShowsPendingShellInput(screen, sanitizedCommand) matches. A human-corrupted line (ng + command fragments) fails the match — the engine correctly refuses the mutation, but then nothing clears and retypes, so the spawn wedges until a human presses Enter. clearAndVerifyFreshShellPrompt (ctrl-c + re-verify) exists but evidently did not run/recover in this scenario.

Asks

1. Shrink or eliminate the focus window. If cmux offers any PTY-direct write that initializes an unfocused tab, use it. If not: focus → immediately restore the user's previous focus after terminal init, before the shell-ready wait (the typing window is currently seconds long).
2. Detect foreign characters and recover. When the pending-line check fails because the line contains MORE than the sent command (human prefix/suffix), clear the line (ctrl-u), retype, re-verify, then submit — instead of stalling.
3. Surface the wedge. A spawn whose launcher line never submitted should go to an error/blocked state with a receipt saying so — not sit in booting until a human notices. (Same family as fix: make prompt freezes observable #418 blocked_on_prompt.)

Related: #432 (busy-send false-fail), boot-prompt-late issue filed alongside this one.

— cmuxlayerClaude (lead) · claude-code/claude-fable-5

[EtanHey]

v0.4.39 live probe: recovery does NOT cover the pre-readiness window

Two live probes on v0.4.39 (daemon confirmed running 0.4.39), 2026-08-17 ~23:15-23:19, keystrokes landing while the spawned pane awaited shell readiness (probe 1: injected via osascript; probe 2: Etan typing on purpose):

Timed out after 10000ms waiting for shell readiness on surface:141
 ngff%     etanheyman ~  $ wenfnng
Timed out after 10000ms waiting for shell readiness on surface:143
rbgjrbgjrbgjrb%     etanheyman ~  $ gjrbgjbrgjrbgjrbgjrgbjrgbjrgbjrgb

What shipped in #438 works only AFTER the launcher command is typed (corrupted pending command line → clear/retype). But keystrokes during waitForLaunchShellReady put junk on the prompt line, readiness never passes, and the spawn fails — the wedge is gone (loud error + error state, screen evidence in the receipt), but the spawn still cannot survive a human typing during boot, which is the original report's exact timeline.

Remaining fix: during the readiness wait, when a prompt is visible but the line carries pending input, clear the line (ctrl-u) and re-check, bounded; only then time out. Also: the failed surface + junk shell stays open (surfaces 141/143 remained) — decide close-on-failure vs forensics-keep and make it deliberate.

— cmuxlayerClaude (lead) · claude-code/claude-fable-5

[EtanHey]

Probe 3 (worse): human Enter EXECUTES the junk, receipt reports clean success

Third live probe, same night: keystrokes (djns, sjnfjdnsf) landed during the readiness wait; the spawn hung until the human pressed Enter; that Enter executed the junk as a shell command (zsh: command not found: sjnfjdnsf) in the worker's shell; the launcher then ran and the spawn returned a fully green receipt (submit_verified:true) with zero trace that a human unblocked it or that arbitrary text was executed.

Two additional asks on top of the readiness-window recovery:

1. Clearing junk with ctrl-u (instead of waiting) also prevents accidental execution of whatever the human typed — that text could have been a real command.
2. Receipt honesty: a boot that only became ready after junk was observed/cleared/executed must say so (readiness_recovered + evidence), never report an untouched clean boot.

— cmuxlayerClaude (lead) · claude-code/claude-fable-5