EOF on a pipe is a reference count reaching zero, not a notification that your command finished [14]. `tail -N` without `-f` cannot emit a line before that count drops, because it does not know which lines are the last N until the stream ends [12]. `head -N` looks safer, and usually is, right up until total output comes in under N lines, at which point it waits for EOF too [13]. Both ends of the idiom are exposed, which is why a rule written after the first two cases mentioned only `tail` and did not cover the third [19].
The process holding the write end does not have to be related to your command. On the 2026-08-15 case, `lsof` on the blocked `head` showed fd 0 reading pipe address `0x4881848dc2e3034f` [8]. An `npm exec xcodemcp@latest` process, spawned in the same second and connected to nothing the author had typed, held fds 5 and 6 on that same address [9]. The 2026-08-14 pair matched the same way, one against `xcodemcp` again and one against `@modelcontextprotocol/server-redis` at pipe `0xe3e977fcc256b0c7` [10][11]. All three confirmed holders were `npm exec` children [2]. The author attributes the inheritance to a missing `close-on-exec` and says so with a hedge, which is the right amount of confidence for evidence that is a matching descriptor address rather than a traced fork [14].
The wrapper timeout cannot see any of this. `alarm 45` fires against the process that `exec` replaced, meaning the vendor CLI, and the CLI has already exited by the time the truncator is stuck [15]. Escalating the value for weeks changed nothing [15], and the scale gap says why: the idiom sets 45 seconds, and one case sat 4860 seconds, 108 times that [1].
The reason this survived weeks of notes is that the same defect produces two different verdicts. A caller that simply waits records an infinite hang. A caller with its own timeout records empty output, and empty output reads as a dead endpoint or a vendor outage [16]. The second version is the one that got written down about a third party [16].
What came out of the 81-minute pipe settles the diagnosis. Killing the write-end holder let `tail` finish in about two seconds, and the payload was 36 bytes: `Error: timeout waiting for response` [17]. The CLI had failed in the first second and said so, and the pipe held that sentence for 81 minutes [5][18]. The failure signal never arrived, and that teaches you to distrust a tool that reported accurately and on time [18].
The fix is cheap and slightly worse to use. Redirect to a file, let process exit close the descriptors, then cut the file [20]. You get correctness and you give up incremental output, because nothing is read until the command has exited [4]. Skipping the shell pipe entirely is the structural version, and a runtime that defaults descriptors to close-on-exec removes the inheritance path, as Python has since PEP 446 [21].
Three cases in one person's terminal is a claim about that terminal. For it to transfer you need a shell pipe into a truncator without `-f`, and something in the same session spawning short-lived processes that inherit fds. Agent tooling launched through `npm exec` fits that description [2].
