[fdaviddpt]

Closes #1040

Thanks to @gwangyong-kim for the report, the measurements, and the read -N fix it suggested: the root cause, the per-byte select() under Cygwin/MSYS, and the redirect-hides-it detail were all in the issue and all held up.

What changed

• New scripts/lib-stdin.sh: _remember_read_stdin_into VAR reads stdin in read -N 1048576 -t 1 chunks on bash 4.1 and later, and keeps the old read -r -t 1 line loop on bash 3.2 (stock macOS) or when REMEMBER_NO_READ_N=1 (the same kind of seam as REMEMBER_NO_PRINTF_T, so CI on bash 5 still runs the 3.2 path). A terminal on stdin is still never read, and each read still gives up after 1 s of silence.
• post-tool-hook.sh, user-prompt-hook.sh and session-end-hook.sh read through it. The compiled release hooks carry it inlined (compile_hooks.py handles it like any other sourced library; checked in the built tree).
• session-start-hook.sh keeps the line loop, on purpose, with a comment saying why: its compiled form sits 37 bytes under the 120 KiB budget in check_release_tree.py (122843 bytes on main), and the inlined library is about 1.2 KB, so routing it through the library failed the release check (124079 bytes, observed). Its payload is ids, paths and a source word, a few hundred bytes, so the per-byte cost there is milliseconds. A test pins this exception.

The trailing newline, and what the extractors see

The old loop dropped every newline: read strips each line ending and the loop joined the lines bare. read -N keeps them. I chose to remove them again, all of them, so the string the JSON field extraction and the hooks.d listeners see is byte-for-byte what the old loop produced (a newline in JSON is whitespace between tokens, never inside a string value). The tests compare against exactly that, payload with newlines removed, for every hook and every reader path.

Two obvious ways to remove them turned out quadratic in bash, found while writing this, so neither is used:

• ${buf%$NL} on a payload WITHOUT a trailing newline: 165 s for 1 MB (bash 5.3, macOS, measured).
• ${buf//$NL/} on a pretty-printed 840 KB payload: 8 s under a UTF-8 locale.
  The library does one [[ == *$NL* ]] scan and, only when that finds one, an IFS split and printf -v join (0.03 s for the same 840 KB). A test bounds all three shapes.

Tests

tests/test_hook_stdin_chunked_read_1040.py, red first (commit 067f507 pushed alone):

• Correctness per hook: each hook extractor, cut verbatim from the hook, fed what the reader produced from a real pipe (subprocess stdin=PIPE, never a file redirect). Payloads: small, 400 KB of long lines, pretty-printed 300 KB, no trailing newline, trailing newline, multibyte UTF-8 (large and small), empty stdin. Readers: chunked, the line-loop fallback, and /bin/bash 3.2 where the host has one.
• A 1 MiB+ multibyte payload under LC_ALL=C (chunk boundary inside a character) and UTF-8: byte-identical.
• A pipe held open with nothing in it still returns in about 1 s, empty.
• post-tool-hook.sh end to end through a pipe: session_id, transcript_path and cwd observed through the capture-alive marker, the post-tool-hook: ~1.2 s per tool call on Windows (0.33.0) - whole-transcript wc -l grows with the session; lib-slug spawns cygpath twice per call #913 scan sidecar, and the store landing in the payload cwd.
• Timing: 1 MB piped to post-tool-hook.sh under 15 s, with a small-payload positive control under the same bound.
• Existing tests adjusted: line-number allowlist in test_locale_ranges_695.py, lib-stdin.sh added to the stub plugins in test_save_session_gates.py and test_session_end_hook_345.py.

Evidence, per platform

Observed:

• windows-latest, red run on 067f507 (old loop): the 1 MB timing test took 32.58 s (bound 15 s); the small-payload control passed.
• windows-latest, all four Python legs and the compiled leg green on 2bcebc9; the 1 MB test is not among the 25 slowest tests there, so under 4.3 s.
• ubuntu, Windows 25H2: every hook fork leaks a kernel Token object until reboot (win32k CForegroundLaunch bug) — fork tax is a persistent leak, not just latency #1011 whole-hook strace total on the below-threshold path: HEAD 62 on all 9 runs, against v0.42.4 68 and v0.43.0 69 (budget under 67). Sourcing a library forks nothing.
• macOS locally: bash 5.3 and /bin/bash 3.2 both green on the new file; the targeted suites (Windows 25H2: every hook fork leaks a kernel Token object until reboot (win32k CForegroundLaunch bug) — fork tax is a persistent leak, not just latency #1011/post-tool-hook creates ~67 processes per no-save tool call #1029 spawn counts, Hook stdin extractors never decode JSON escapes: Codex on Windows yields a doubled-backslash PROJECT_DIR and the wrong session slug #829, The first-match stdin extractor now feeds cwd on all four hooks, and #344's top-level-wins pin only ever covered source #447, _stdin_json_string takes the FIRST "source" key, so a future nested payload could suppress the recap at a genuine startup #344, PostToolUse still cannot save on Codex: the session id is taken from the transcript basename, which #459 stopped controlling #468, post-tool-hook.sh: transcript-scan cache is never used on Windows (backslash transcript_path), so every PostToolUse call rescans the whole transcript #1034, post-tool-hook: offset-0 transcript scan still exceeds the 600 s host timeout on large transcripts (Windows, 0.43.1; follow-up to #1017 and #1034) #1036, Hook scripts fail with "Argument list too long" #266 stdin size, compile_hooks and compiled pins, locale ranges, scanner shapes) green, also against a locally compiled tree; release tree built from HEAD passes check_release_tree.py and the hook smoke (claude plugin validate skipped locally, it fails on main here too).
• macOS bash 5.3: 1 MB piped through the chunked reader in about 0.4 s.

Reasoned, not observed:

• The real-world Windows speedup for a user: the reporter measured 0.45 s for the chunked read of 1 MB on their machine; CI shows the whole hook well under the old cost, not a desktop timing.
• bash 4.1 to 4.4 take the chunked path; no CI leg runs those versions.
• A side finding: the old loop timeout is per line, so on Windows it fired roughly every 40 KB in the middle of a single long payload line. On macOS bash 5.3 under load, with the line loop forced, a timeout inside a multibyte character was seen to change a byte. The chunked read makes that far less likely on Windows; the bash 3.2 path keeps the old behaviour.

🤖 Generated with Claude Code

[AI-generated]