2.1.141: Notification:permission_prompt hook event stops firing during active thinking (regression from 2.1.139)

[ww2283]

Summary

In 2.1.141, the Notification hook event with notification_type: permission_prompt does not fire when a permission prompt appears while the assistant is in an active thinking phase. The prompt renders correctly in the TUI; downstream hooks subscribed to Notification never run.

Confirmed working in 2.1.139 with the same project, settings, and hook scripts. 2.1.140 not tested.

Repro

1. Configure a Notification hook with matcher permission_prompt:

   "Notification": [{
     "matcher": "permission_prompt",
     "hooks": [{"type": "command", "command": "/tmp/log-prompt.sh"}]
   }]

   where log-prompt.sh is echo "$(date '+%H:%M:%S') fired" >> /tmp/prompts.log.
2. Run any task in extended-thinking mode that triggers a permission prompt mid-reasoning. The unsandboxed-Bash override prompt is reliable because it always appears mid-thinking.
3. Observe: prompt renders, user sees it. /tmp/prompts.log gets no new line.
4. Downgrade to 2.1.139, repeat. /tmp/prompts.log gets a new line for every prompt.

PreToolUse and AskUserQuestion hooks fire correctly on 2.1.141 — only Notification:permission_prompt is affected.

Suspected mechanism (from the 2.1.141 binary)

The permission_prompt Notification trigger is gated by a 6-second user-idle check:

const NIK = 6000;

function AR()  { return m_.lastInteractionTime; }
function hF3() { return Date.now() - AR(); }
function EF3(H){ return hF3() < H; }
function SF3(H){ return !EF3(H); }            // idle ≥ H ms

function KG_(message, notificationType) {     // permission_prompt path
  ...
  P1(() => {
    if (SF3(NIK)) {
      setFired(true);
      MHH({ message, notificationType }, q);   // ← actual hook fire
    }
  }, fired ? null : NIK);
}

m_.lastInteractionTime is reset by bt8() (called via u6H(true) → Ci8()). Ci8() is invoked from the SDK control-request handlers:

if (plK(K.request)) Ci8(...)   // adjacent to can_use_tool / pendingRequests
if (mlK(_))         Ci8(...)   // adjacent to onControlRequestResolved

The release note for 2.1.141 mentions the spinner now warms to amber after 10 seconds during long thinking periods. That feature appears to emit periodic progress/heartbeat control messages on the same channel — each tick matches plK/mlK, calls Ci8 → bt8 → lastInteractionTime = Date.now(). The 6-second idle window never accumulates during thinking, so SF3(6000) stays false and MHH(...) is never reached.

Symbol names may roll in subsequent versions; the structural pattern is KG_(..., "permission_prompt"), gated by SF3(NIK) with NIK = 6000, with lastInteractionTime reset via Ci8() from control-request predicates.

Impact

Any hook subscribed to Notification:permission_prompt silently misses prompts that arrive mid-thinking. The terminalSequence hook output field added in this same release is also effectively unreachable for permission_prompt, since it depends on the parent event firing.

Suggested fix

Exclude progress/spinner heartbeats from the user-interaction reset. Options:

• Narrow plK/mlK predicates so spinner heartbeats don't match.
• Tag heartbeat control messages and skip Ci8() for them.
• Decouple the permission_prompt Notification gate from lastInteractionTime — user-input idle is the wrong proxy when the assistant is what's keeping the system "active".

Environment

• claude-code 2.1.141 (Mach-O arm64, macOS 25.5.0)
• Verified working: 2.1.139
• Not tested: 2.1.140
• Terminal: VS Code Insiders integrated terminal + tmux; also reproduces in Ghostty

[DanielPVG]

Same v2.1.142 extension bug not fire for LLM tool calls

[ishii1648]

Tested 2.1.140 and the Notification:permission_prompt hook fires correctly with the same setup as the original post, so the regression appears to have been introduced in 2.1.141.

[vimholic]

v2.1.143 also broken — and the scope has expanded beyond permission_prompt.

Repro confirmed on Claude Code 2.1.143 (CLI, WSL Ubuntu, terminal — not VS Code extension):

• Edit/Write permission prompt for external paths → notification_type=permission_prompt → no hook fire
• AskUserQuestion → notification_type=idle_prompt (per CLI behavior we observed) → no hook fire

Cross-check on the same workstation:

• 2.1.142 (installed 2026-05-15 08:00 KST): idle_prompt hook fired 4 times in real interactive sessions (timestamps 22:33, 22:55, 22:58, 01:47 — confirmed in /tmp/claude-hooks.log entries with hook_event_name:"Notification", notification_type:"idle_prompt")
• 2.1.143 (installed 2026-05-16 07:30 KST): 0 Notification events in 30+ minute interactive session with multiple AskUserQuestion calls and external-path Edit prompts

The original report describes permission_prompt-only breakage during active thinking on 2.1.141. On 2.1.143 the breakage extends to idle_prompt and AskUserQuestion-driven notifications, even when the assistant is not actively thinking (e.g., right after a tool result returns and the prompt appears synchronously).

PreToolUse / PostToolUse / Stop / SubagentStop / TaskCompleted all fire normally on 2.1.143 — the Notification family alone is silent.

Hook registration is unchanged across versions (matcher=*, single command pointed at a bash script). Mock JSON injection into the hook script works, so the issue is upstream from the hook entry point.

Suggest the suspected mechanism (lastInteractionTime reset via control-request heartbeats) be re-examined for the broader notification_type set, not just permission_prompt mid-thinking. Possible that v2.1.143 widened the gating predicate or applied the same reset path to idle_prompt/elicitation_dialog emission.

Environment: WSL Ubuntu, bash hooks at ~/.claude/hooks/notify-hook.sh, settings.json registers Notification with matcher=*. Same binary checksum on two workstations (one home, one office) — same 0-event behavior on both after upgrading to 2.1.143.

[juanluiscr27]

Same problem here. I am on v2.1.143

I came here just hoping to find a fix.

[bastewart]

Confirming the 2.1.143 regression on macOS (Sequoia 25.3, arm64). Tmux-tab-colouring chain that touches /tmp/claude-attention-<pane>-<pid> on Notification:permission_prompt and Notification:elicitation_dialog, cleared by UserPromptSubmit/PostToolUse/SessionEnd. Worked reliably until the auto-update to 2.1.143 this morning.

Repro on 2.1.143 with a debug logging hook on Notification (matchers permission_prompt, elicitation_dialog, idle_prompt, and empty wildcard) showed zero Notification entries across two AskUserQuestion calls and a /usr/bin/say invocation, while PostToolUse fired six times in the same window. Downgrading the symlink to 2.1.140 immediately restored the integration — including the AskUserQuestion path, which is currently spun out as #59908 but is part of the same regression at our end.

This matches @vimholic's report that the Notification family is silent across the board on 2.1.143, not just permission_prompt mid-thinking. Could this be reopened given the regression has widened beyond the originally-reported scope?