[raiseCatError]

Draft, do not merge before v0.21 ships. #430 has carried dev into release/v0.21.0; a fix v0.21's physical QA needs would reach the release the same way, so anything merged into dev before the release would ride along. Part of v0.22 (#431). Now based on #433 (fix/v022-input-ownership-look): #433 merges first, then this PR. Its diff is #436's fix, the merge with #433, and the combined fix below.

#436: reproduced and explained

The issue recorded one live failure of a command typed right after a read returns, or right after Ctrl+C, reaches the shell once, in order and a guessed cause. The guess was wrong. An instrumented copy of the test (8 at a time, load ~30, never committed) reproduced it on unmodified dev, in 6 of 8 copies in one round and 4 of 8 in another. The command that ran was the typed line with its beginning missing: olumes/…/once, cho Y >> …/once, exit 127. A frontend log of every input-state change and hand-over showed two mechanisms:

1. A late report of the question Ctrl+C ended. The session sampled read -r reply (likely line) before it saw the interrupt; the report reached the frontend after Ctrl+C. onInputState saw a draft typed after the question began and re-marked the post-Ctrl+C type-ahead as a reply; when the prompt came back (exit 130), "a reply typed for a finished command is discarded" cleared the composer mid-typing. The rest of the line was typed into an empty composer and ran truncated.
2. The shell's own prompt hooks read as the command waiting. After a command ends, zsh/Bash run their prompt hooks (the person's and NMSh's) before the prompt marker. A slow hook holds the terminal, idle, with line settings, which is exactly what a builtin read looks like, so the watch reported "Probably waiting for input" (since 5 ms after the stop, so not stale). Same discard. This one is not tied to Ctrl+C or load: any slow prompt hook (a heavy theme, nvm) reproduces it deterministically at normal load.

Fix, at each cause

• Stale questions (TerminalApp.onInputState): a request that began before Ctrl+C or Ctrl+Z is the one the stop ended. It is dropped: it never turns post-stop typing into a reply, nor routes keys to the program. A question asked after the stop is new and handled as before.
• A done marker (shell protocol): each shell's first prompt hook prints an authenticated done before anything else runs. zsh: nmsh_done, kept first in precmd_functions, passes the command's status on unchanged (checked: later hooks see the real $?). Bash: the first line of __nmsh_precmd. Fish: the first line of the postexec handler. ShellSession passes it to InputWatch.onDone(), which closes any open wait at that moment, cancels its schedule and drops a sample already under way. Nothing is sampled again until the next command.

Verification

• Regressions first, each failing on dev:
  • tests/ctrlCTypeAhead.test.ts replays the logged sequence: the late report never discards the draft; a stale hidden report does not route type-ahead to the program; a new question after the stop still does. Both fail on dev (the first exactly as live: composer cleared at the prompt).
  • tests/promptHookLive.test.ts (real zsh and Bash, a deliberately slow prompt hook of the person's: zselect / a timed read on a FIFO; a draft typed during it): both fail on dev at load 3 (Waiting for input shown for the hook). Both pass here.
  • Unit: the done marker is authenticated and split-safe (tests/shellProtocol.test.ts); after done an in-flight sample is dropped, nothing is sampled, an open wait closes at that moment, and the next command is watched again (tests/inputAwareness.test.ts).
• Live comparison (instrumented reproducer, 8 at a time, load 20–30): dev failed with the symptom in 6/8, 2/8, 4/8 and 2/8 copies over several rounds. With only the stale-question fix, one symptom remained, and the log identified mechanism 2. Its own live test then failed at load 3 and passes now.
• Suites: shell protocol, shell session, Powerlevel10k (hook composition), shell frameworks, adapters, shell switch, input awareness and ownership (unit and live), typing after read, query order, command queue: all pass. Full canonical npm run verify on 9aae2f03 (NMSH_TEST_TMPDIR=/Volumes/T7Tmp/ai-dev, load 3–15): exit 0, 3,149 tests, 3,147 pass, 2 skipped, 0 failed.

Review follow-up (second commit)

An automated security review pointed out that the first version dropped a question that began before Ctrl+C for the rest of the command. If that stayed the session's latest word (a program that read through the stop), the frontend would never be told again, and a later password could be drawn. Now:

• the stale question is ignored only during the 2 s type-ahead window after the stop; if it is still the session's word when the window closes, it applies then, so a hidden question goes back to direct, never-drawn input;
• a draft begun in that window is type-ahead for the prompt: never flipped to a reply nor handed to the program, whatever arrives later.

Regression: tests/ctrlCTypeAhead.test.ts "a question still open after the type-ahead window … applies again" fails without it.

Full npm run verify on the second commit (83135298) ran while the machine was at load ~20–23 from other work: 3,150 tests, 3,142 pass, 2 skipped, 6 failed: live startup timeouts (timed out waiting for /zsh|bash/u) in promptHookLive, queueConditionsLive, muxInterop (×2) and sessionLifecycle, plus a timing bound in contextKernel. All six files then passed 46/46 rerun at load 11–14. A clean full run on the final head is still owed before this leaves draft.

Combined with #433 (4556dfab merge, e2776680 fix)

The two PRs conflict in InputWatch.ts. The resolution is not just textual: it decides what held typing (#433) does when the shell's done marker (this PR) says the command finished. That marker reaches the session before the prompt reaches the frontend.

The danger, shown by regressions written against the plain merge (they fail there):

• A look that answered 'idle' after done settled held typing as if the command were still running, so its Enter queued it.
  • A password typed for a read -rs -t 1 that gave up was queued as a shell command.
  • Typing held past the slow mark was queued too.
• A probe the command finished during dropped its evidence of hidden input: 'idle' instead of 'hidden'.

The fix:

• Session (InputWatch):
  • A look after done answers 'idle' without probing its prompt hooks.
  • A sample the command finished during is not applied, so no question is reported, but its evidence still counts: seen hidden input (line input with echo off) is reported 'hidden'.
• Frontend (TerminalApp):
  • An 'idle' answer means the command ended for that hold, so Input ownership: keys wait for the look, however long a loaded machine makes it (#426) #433's rules for a command that ended apply at once. A reply, typing held past the slow mark, or typing a look saw as hidden is discarded with a note, never shown, queued, sent or run.
  • Plain type-ahead that the look cleared at once stays for the next command, and runs only on the person's Enter.

Why ordinary type-ahead during slow hooks is unaffected: measured in real PTYs, prompt hooks run with zsh 5.9 and Bash 5.3 at icanon echo (visible line input), and with Fish 4.9.3 at -icanon -echo (its own key mode). None looks hidden. A hook that really turns echo off is treated as possibly sensitive, which is the safe direction.

Combined regressions: tests/inputOwnershipDone.test.ts (deterministic; 4 of 8 fail on the plain merge, one of those a test timing fix):

• Watch: a look after done answers 'idle' and never probes; hidden evidence from a look the command finished during is kept and never applied; visible evidence answers 'idle', and the next command is looked at afresh.
• Frontend, done before the prompt:
  • a reply seen as hidden is discarded, never drawn, queued, written or run;
  • typing held past the slow mark is discarded;
  • plain type-ahead is kept and runs once on Enter.
• Interrupt: Ctrl+C discards held typing; a late look answer and a stale question after it change nothing; typing after Ctrl+C survives the prompt.
• Process exit: the look is unanswered when the command exits; late evidence and the next command never see the old typing.

Verification on e2776680:

• Deterministic suites: the combined, Input ownership: keys wait for the look, however long a loaded machine makes it (#426) #433 and Flaky under parallel load: a command typed right after Ctrl+C on a waiting read can fail to run #436 suites, plus input awareness and the shell protocol: 61/61.
• Live: promptHookLive 2/2 and inputOwnershipLive 6/6 (zsh, Bash, Fish), at load 15–30 with under 100 MB of free memory.
• Full local run: not repeated under this memory pressure; CI runs on this head.

Follow-ups from the v0.22 candidate (e391bcb0, 807d3c03)

A regression in the combined fix, caught by the candidate's CI (Ubuntu zsh, typingAfterRead, with #442's stricter check):

• What happened: after NMSh answered a read -s, the next command typed at once was held for a look. The look still saw the answered question (echo off until the read returns). Counting that as possible password input discarded the next command when the read finished.
• Fix (e391bcb0): hidden input seen after this command's hidden question was answered is that question, not new evidence.
• Regression test: fails before the fix.

The automated security review of that commit was right: the grace was unbounded.

• The danger: a second hidden question (read -s a; read -s -t 1 b, or a sudo retry) would have its reply treated as type-ahead, and run if the command then ended.
• Fix (807d3c03): the grace covers only typing begun within 1 s of the answer, and a newer question reported by the session ends it at once.
• Regression tests (both fail before the fix): a second prompt-less hidden question typed after the window; a sudo retry reported before the typing.

Rule now:

• A reply typed before NMSh answered anything, typing held past the slow mark, and a reply to a newer hidden question are all discarded when the command ends, never run.
• Only type-ahead begun right after an answer, with no newer question, stays for the next command.
• Residual: two prompt-less hidden reads in a row, the second's reply typed within 1 s and finished within 800 ms, then the command ends before NMSh sees the second question. That reply is kept as type-ahead, as a plain terminal would deliver it.

Verification on 807d3c03: deterministic input suites 64/64. On the candidate (567cf533): live typingAfterRead 3/3 and inputOwnershipLive 6/6; CI dispatched.

Limits

• zsh's single precmd function (not the array) runs before nmsh_done, and Fish runs other fish_postexec handlers in an order NMSh does not control; a slow hook there can still be sampled. NMSh's own hooks, and every hook registered in precmd_functions or PROMPT_COMMAND, come after the marker.
• A sample that started before the shell printed done, and finishes before the session has read it, can still be applied. The window is now the time to read PTY output, not the duration of the hooks.
• This does not claim the whole input-race family is solved. Under heavy load, a reply typed right after a prompt-less read starts can be queued instead of answering it #426 (Input ownership: keys wait for the look, however long a loaded machine makes it (#426) #433) covers keys held while the session looks, and Flaky: Fish can lose keys typed right after a handed-over read returns #356 (Fish typeahead after a handed-over read) stays open and unreproduced.

Physical QA (not done)

Ghostty and Terminal.app, zsh, with a slow prompt hook that holds the shell itself (an external sleep would not): zmodload zsh/zselect; slowp() { zselect -t 150 }; precmd_functions+=(slowp) in ~/.zshrc. Run true, type the next command while the prompt is coming back → no "waiting for input", the draft stays and runs once (Bash is covered by the automated live test). read -r reply, Ctrl+C, type a command at once → the whole line runs.

Refs #436

[raiseCatError]

Release security review (v0.22.0, #444): 6486d9c5. Two paths still let a password run as a shell command on the green candidate 567cf533. Both are now fixed.

1. A reply held after a hidden answer. For 1 s after NMSh answered a hidden question, a look that still saw hidden input was attributed to that question. If the command then ended, the held typing ran as the next command. A second question with no prompt that gave up first (a timed read) is indistinguishable, and a time window is no proof.
   • Now that typing waits at the prompt, hidden: Typed during <program>'s hidden input · held, not run · Tab shows it · Esc discards it.
   • No timer, later look or next command settles it.
   • The 1 s window now only separates a probable reply (discarded) from unconfirmed typing (held).
2. A reply queued before its question. A reply typed and entered before a question with no prompt existed is queued like any command.
   • When the command then asks for hidden input, the entries queued while it ran wait for approval. An older service pauses the queue instead.
   • Each question is checked once. Entries queued before the command, or with Ctrl+Q during the question, are left alone.
   • The question's since is not used as a boundary, because the watch can date it to when the shell went idle (a sleep before the read). The live test showed this.

NMSH_DEBUG_KEYS never logs typing held at the prompt.

Tests

• tests/inputOwnershipSecrets.test.ts, 10 deterministic tests. 6 fail before the fix.
• tests/inputOwnershipSecretsLive.test.ts, live zsh and Bash. On 567cf533 the second password of read -rs a; sleep 3; read -rs b ran as a command and was recorded in NMSh's journal. With the fix it never runs, and it is not in the shell's history file.
• This PR's test "type-ahead after answering a hidden question" now expects that typing to be held, then run once on Tab and Enter.
• typingAfterRead (here, and in Tests: live tests wait for NMSh's journal, not screen text (CI races seen on #441 and #442) #442's version) accepts that held outcome only for typing ahead during a hidden read, and still requires the command to run exactly once.

Locally on this branch: input-ownership suites 45/45 and related suites 107/107. Live: typingAfterRead 3/3, inputOwnershipLive 6/6, promptHookLive 2/2, the new live test 2/2. Type check clean.

[raiseCatError]

Its commits (head 271e67bb) are in master and dev through v0.22.0 (https://github.com/raiseCatError/notMyShell/releases/tag/v0.22.0). This PR was stacked on #433's branch, so GitHub cannot retarget it to dev (no new commits) and it cannot show as merged; closing as completed. The branch is kept.