[BUG] Notification Hook 10 second delay

+1 Having same issue

Environment

Platform:

• [x] Anthropic API

• Claude CLI version: 1.0.72
• Operating System: Ubuntu 24.04.2
• Terminal: Zsh

I've been battling with this for a TTS based on the notification hook. Mine isn't quite 10 seconds but it's lengthy. I though it was my hook handlers and have put extensive logging in my code and my hook handler in Python take 50ms total. Not great but definitely not the 3-6 second delay the hook shows. I have logging of the notification as the first thing that happens and I see the file get written ad is immediately followed by my TTS announcement.

I'm certain it is not my code.

Anthropic API

Claude CLI version: 1.0.72

Operating System: macOS Sequoia 15.6

Terminal: Zsh

same issue here

[DEBUG] Hooks: checkForNewResponses called
[DEBUG] Hooks: Found 0 total hooks in registry
[DEBUG] Hooks: checkForNewResponses returning 0 responses

then delay for 10~20s

I am on windows11, claude code 2.0.0,

CPU: AMD ryzen 9 9950X

Seems I fixed this issue by https://stackoverflow.com/questions/28507014/cygwin-commands-from-cmd-are-slow-from-bash-are-fast. Problem is cygwinis very slow when frist time called on windows.

A section in Cygwin's FAQ addresses slow startup times. Cygwin recently changed to using Active Directory lookups for authentication, rather than using flat files. Changing the defaults in /etc/nsswitch.conf from passwd: files db group: files db to passwd: files group: files skips the AD lookup. My Cygwin commands are now speedy again.

Has anyone got a fix on linux?

I'm also getting this

Bumping this

This problem is still happening.

im getting this bug too and its really disrupting my workflow at work!

Bumping this again

Bumping this

I want to be notified as soon as possible when Claude needs my attention. These 10 second delays are annoying.

@bcherny @ant-kurt @ashwin-ant Can you help with this? v2.0.37 included "Fixed how idleness is computed for notifications" but there's still a consistent ~10s delay in the notification pipeline.

Binary analysis (v2.0.55) shows a 6-second polling interval (setInterval with ewD=6000) in the notification check logic. The remaining ~4 seconds may be subprocess spawn overhead. On Windows/Cygwin, disabling AD lookups in nsswitch.conf reduces the delay, supporting this theory.

Relevant timing constants found in the bundled JS:

• ewD=6000 (notification polling interval)
• Tz=60000 (hook execution timeout)
• asyncTimeout=15000 (async hook timeout)
• messageIdleNotifThresholdMs=60000 (idle notification threshold)

Exposing the polling interval as a configurable environment variable would help.

In the meanwhile I had Claude Code make a program that patches this bug on your local binary: https://gist.github.com/cool-RR/dab9b132fb607712a614d487dd554d29

For me it makes the notification hook have <1s delay. Use at your own risk.

I can confirm this bug on Linux with Claude Code 2.0.65. Seems to be much longer than 10 seconds for me though. I'd expect the notification to be instant.

Confirming this bug still exists on v2.0.76 (macOS)

This bug still exists on v2.1.11 on Mac

In the meanwhile I had Claude Code make a program that patches this bug on your local binary: gist.github.com/cool-RR/dab9b132fb607712a614d487dd554d29 For me it makes the notification hook have <1s delay. Use at your own risk.

thank you for this gist. I modified it to work with 2.1.x and included it in my MIT licensed tool, lemonaid: https://github.com/petergaultney/lemonaid/blob/main/src/lemonaid/claude/patcher.py

Seems I fixed this issue by https://stackoverflow.com/questions/28507014/cygwin-commands-from-cmd-are-slow-from-bash-are-fast. Problem is cygwinis very slow when frist time called on windows. > A section in Cygwin's FAQ addresses slow startup times. Cygwin recently changed to using Active Directory lookups for authentication, rather than using flat files. Changing the defaults in /etc/nsswitch.conf from > passwd: files db > group: files db > to > passwd: files > group: files > skips the AD lookup. My Cygwin commands are now speedy again.

UP the issue.

This fix is not working if using Native Install. I tested and it is only works with npm install on windows 11.

I'm seeing this bug on Mac v2.1.39 for Notification hooks as well.
The Stop and SubagentStop fire immediately.

Have this problem on Windows Terminal too. 60 seconds delay...

In my case this solved the problem for 60 second notification delays: https://github.com/anthropics/claude-code/issues/13922#issuecomment-4009049985

Still present on v2.1.116, macOS 15.7.4 (arm64). Adding timing data that might help isolate:

  ▎ From my hook debug log, PreToolUse and PostToolUse fire with <1s latency. The delay is specifically between tool dispatch and the permission_prompt Notification:    
  ▎ 15:08:30 PreToolUse(Read)              
  ▎ 15:08:36 Notification(permission_prompt)   ← 6s gap                                                                                                                  
  ▎ 15:14:59 PreToolUse(Bash)                                                                                                                                            
  ▎ 15:15:05 Notification(permission_prompt)   ← 6s gap                                                                                                                  
  ▎ Stop, PreToolUse, PostToolUse, UserPromptSubmit all fire immediately. Only Notification has the delay. 

Bumping this.
Same issue with following info:

OS: Windows 10
Terminal: PowerShell
Claude Code Version: 2.1.128

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.