## Description There is significant latency (seconds) between when a permission prompt or idle prompt event occurs and when the associated Notification hook is actually invoked. ## Reproduction 1. Configure a Notification hook in settings.json: ```json { "hooks": { "Notification": [ { "matcher": "permission_prompt", "hooks": [ { "type": "command", "command": "~/bin-personal/claude-notify.sh" } ] } ] }

High latency in hook invocation for Notification events

Status Open

Maintainer reply None cached

Activity 4 comments · opened Jan 21, 2026

Description

There is significant latency (seconds) between when a permission prompt or idle prompt event occurs and when the associated Notification hook is actually invoked.

Reproduction

Configure a Notification hook in settings.json:

{
  "hooks": {
    "Notification": [
      {
        "matcher": "permission_prompt",
        "hooks": [
          {
            "type": "command",
            "command": "~/bin-personal/claude-notify.sh"
          }
        ]
      }
    ]
  }
}

Trigger a permission prompt (e.g., run a Bash command)
Observe multi-second delay before the hook script executes

Debugging performed

We isolated the latency to Claude Code's hook invocation, not the notification delivery chain:

| Component | Latency |
|-----------|---------|
| Hook script execution | ~15-27ms |
| Tmux passthrough | ~1ms |
| Direct OSC 99 notification | Instant |
| Claude Code hook invocation | Seconds |

When sending notifications directly via printf to the TTY, they appear instantly. The same scripts called via Claude Code hooks have multi-second delays.

Expected behavior

Hooks should be invoked with minimal latency (<100ms) after the triggering event occurs.

Environment

macOS (Darwin 24.6.0)
Running inside tmux
Kitty terminal with OSC 99 notifications

View original on GitHub ↗

4 Comments

github-actions[bot] · 7 months ago

Found 3 possible duplicate issues:

This issue will be automatically closed as a duplicate in 3 days.

If your issue is a duplicate, please close it and 👍 the existing issue instead
To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

petergaultney · 7 months ago

I'm seeing this also. I've been using hooks to keep track of my running sessions, but very recently (since around 2.1.7) their reliability took a huge hit.

maxw1489 · 6 months ago

I got into the same issue. Any notification ~20-45s delay until it fires. I tried to set the hook for permission_prompt or elicitation_dialog, but it doesn't change anything.

Hope to see a fix soon. I am on v2.1.50

*edit: I used the notification hook for a day now and mentioned that on projects where Claude CLI was called from project_root instead of ~ the delay was around ~2-8s. Loving that I can work without waiting much for the hook but it's still a very strange behavior.

pescheck-bram · 2 months ago

Environment:

OS:              Debian GNU/Linux 12 (bookworm)
Kernel:          Linux 6.1.0-41-amd64 x86_64
Session:         Wayland
Compositor:      Sway 1.7 / wlroots
Terminal:        foot 1.13.1

Claude Code:     2.1.190
Node:            v24.7.0
Install:         ~/.local/bin/claude  (native installer)

Additional datapoint: PermissionRequest and Stop hooks fire almost immediately, while Notification does not.

For the same Write permission event, with the permission dialog already visible in the TUI:

PreToolUse (Write)                 +0 ms
PermissionRequest (Write)          +58 ms
Notification (permission_prompt)   +6.017 s

So the delay is not in the shell script or notification daemon. The PermissionRequest hook fires immediately, but the Notification hook for the same permission prompt runs several seconds later.

My hypothesis is that PreToolUse, PermissionRequest, and Stop are executed synchronously in the agent loop, while Notification is handled through a deferred or queued path.

That would also fit the other observations in this thread, such as the idle_prompt timer behavior, delays scaling with cwd, and the Windows duplicate-notification issue.