Adding data points on Cursor 3.1.15 (macOS, 2026-04-21). The postToolUse input side also looks unpopulated, on the same path where the response is discarded — so even fixing the output plumbing wouldn’t be sufficient on its own.
Hook script logs process.argv, CURSOR_* env vars, and stdin length on every invocation. Representative entries:
[2026-04-21T21:53:59.071Z] spawn pid=25047 argv=[] env=
[2026-04-21T21:53:59.077Z] stdin-end bytes=0
[2026-04-21T21:55:37.036Z] spawn pid=26394 argv=[] env=
[2026-04-21T21:55:37.044Z] stdin-end bytes=0
Every invocation: argv empty, no CURSOR_* env vars present, stdin closes with 0 bytes before the hook can read anything. So the hook has no way to know which tool fired, what the input was, or what the response was — it can emit a fixed-shape additional_context but nothing conditional on the event.
The same script installed as a beforeShellExecution hook on the same Cursor version receives full payloads on stdin (~600 bytes with command, session_id, cwd, hook_event_name, etc.), so the stdin plumbing works in other hook types — postToolUse specifically isn’t forwarding anything.
Separately, firing is sporadic. During a ~15-minute session with many Write/Edit tool calls, the hook fires only ~10 times total — often as bursts of 2–3 simultaneous invocations at the same millisecond, then quiet for minutes. Matches the pattern reported on afterFileEdit hook not firing reliably, missing events on batch edits and mid-session for afterFileEdit, possibly a shared root cause.
So three independent postToolUse gaps on 3.1.15:
- Intermittent firing — events dropped during bursts and mid-session
- Empty input payload — no data via argv, env, or stdin
- Output discarded — the fire-and-forget response-handling path this thread already covers
Flagging so all three can be scoped together — a fix that only lands (3) would leave the hook effectively unusable because of (2).