[FEATURE] Configurable timeout for idle_prompt notification hook

Status Open

Maintainer reply None cached

Activity 8 comments · opened Dec 13, 2025

Preflight Checklist

[x] I have searched existing requests and this feature hasn't been requested yet
[x] This is a single feature request (not multiple features)

Problem Statement

The idle_prompt notification hook currently has a hardcoded 60-second timeout before it triggers. For users who multitask while Claude Code is running, this delay means we often don't realize Claude is waiting for our input until we manually check back much later.

I have ADHD and frequently switch between windows while Claude Code works on tasks. When Claude needs my input, I assume it's still processing and continue with other work. By the time the 60-second notification fires (if I even notice it), I've often completely forgotten I was waiting for Claude Code and have context-switched to something else entirely.

I know this seems minor, but for neurodivergent users who struggle with task-switching and working memory, a shorter configurable timeout (like 30 seconds, or even 15) would significantly reduce the friction of working with Claude Code in a multitasking workflow.

Proposed Solution

Add a configurable idle_prompt_timeout setting in settings.json that allows users to customize when the idle_prompt notification fires.

Example configuration:

{
  "idle_prompt_timeout": 30,
  "hooks": {
    "Notification": [
      {
        "matcher": "idle_prompt",
        "hooks": [
          {
            "type": "command",
            "command": "powershell -Command \"(New-Object Media.SoundPlayer 'path/to/alert.wav').PlaySync()\""
          }
        ]
      }
    ]
  }
}

The timeout value would be in seconds and default to 60 to maintain current behavior.

Alternative Solutions

Related issues #13024 and #13830 request immediate notification hooks for AskUserQuestion and other waiting states. Either of these solutions would also address my use case:

A new hook that fires immediately when Claude yields control (issue #13024)
Notification support for AskUserQuestion events (issue #13830)

However, a configurable timeout for idle_prompt would be simpler to implement and wouldn't require new hook types.

Priority

Medium - Impacts workflow efficiency for users with ADHD and other neurodivergent users who multitask

Feature Category

Configuration and settings

Use Case Example

I ask Claude Code to help implement a feature
I switch to my browser to research something while Claude works
After 30 seconds, Claude is waiting for my input
My configured 30-second notification plays an alert sound
I switch back to the terminal and respond to Claude's question
Work continues with minimal context-switching friction

With the current 60-second timeout, I often don't realize Claude is waiting until I've been doing something else for several minutes, making it much harder to resume the task.

Additional Context

I'm a blind screen reader user with ADHD, so audio notifications are essential for me to know when Claude Code needs attention. The notification hook system is excellent, but the hardcoded 60-second delay is just long enough that I've usually moved on mentally to something else by the time it fires.

Even if the configurable range was limited (e.g., 15-60 seconds) to prevent notification fatigue, it would be a huge quality-of-life improvement for users who need faster feedback about Claude's state.

View original on GitHub ↗

8 Comments

davidbeesley · 7 months ago

Would hooks on both Permission Request plus Stop help your use case in the meantime?
https://github.com/anthropics/claude-code/issues/13024#issuecomment-3701826275

Something like

{
  "hooks": {
    "Notification": [
      {
        "hooks": [
          { "type": "command", "command": "notify-permission.sh" }
        ]
      }
    ],
    "Stop": [
      {
        "hooks": [
          { "type": "command", "command": "notify-stop.sh" }
        ]
      }
    ]
  }
}

sylv-io · 7 months ago

Would hooks on both Permission Request plus Stop help your use case in the meantime? #13024 (comment) Something like `` { "hooks": { "Notification": [ { "hooks": [ { "type": "command", "command": "notify-permission.sh" } ] } ], "Stop": [ { "hooks": [ { "type": "command", "command": "notify-stop.sh" } ] } ] } } ``

Hi,
I'm having a similar issue. Ideally, I would like to set the timeout to zero so that a terminal bell is triggered as soon as the prompt becomes idle. As far as I know, hooks cannot be used as a workaround because they don't have direct access to stdout. Or is there a suggestion on how this could be accomplished?

foxfirecodes · 7 months ago

you can still use hooks for this, you'll just have to use an alternative approach other than a terminal bell. here's what i use on macOS:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "afplay /System/Library/Sounds/Ping.aiff"
          }
        ]
      }
    ],
    "Notification": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "afplay /System/Library/Sounds/Submarine.aiff"
          }
        ]
      }
    ]
  }
}

as an aside, it's a bit trickier to do this if you are working over SSH. the workaround i came up with is to run this locally:

ssh -N -R 10001:localhost:10001 <your host>

then in another terminal run:

while true; do nc -l 10001 && afplay /System/Library/Sounds/Ping.aiff; done

then you configure claude in your remote machine like so:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "echo done | nc -N localhost 10001"
          }
        ]
      }
    ],
    "Notification": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "echo done | nc -N localhost 10001"
          }
        ]
      }
    ]
  }
}

(the -N flag for nc closes the connection after it receives an EOF, this works for me on Ubuntu but might differ across systems)

zhijun42 · 6 months ago

+1 on this. I use Claude Code in JetBrains IDE terminals which don't support OSC 9 notifications, so I built a custom Notification hook that sends native macOS banner notifications via the UNUserNotificationCenter API.

The hardcoded 60-second idle threshold is too aggressive for my workflow — it typically takes me ~2 minutes to read through a long Claude response. As I'm actively reading, Claude will pop up the 60s idle notification, because it can't tell whether I'm reading the terminal right now. This is annoying.

I tried several workarounds to extend the delay:

sleep 60 in the hook to add an extra 60s delay — works, but if I start typing my next prompt between 1-2 minutes, the notification still fires because there's no way to cancel it.
Wiring UserPromptSubmit hook to kill the sleeping process — works in theory, but in practice I'm still reading the response when the 60s sleep expires, so the cancellation window doesn't help.
Debouncing with timestamp files — doesn't help since the Notification event only fires once, not repeatedly.

The fundamental issue is that there's no [1] "no longer idle" event or [2] configurable idle threshold. A notificationIdleSeconds setting in settings.json would solve this cleanly.

MosheBenZacharia · 5 months ago

add this to your ~/.CLAUDE.json

"messageIdleNotifThresholdMs": 5000,

(this is 5 seconds)

yurukusa · 5 months ago

You can't change the idle_prompt timeout, but you can add a faster parallel notification via a PostToolUse hook that detects when Claude is about to prompt for input:

osascript -e 'display notification "Claude needs your input" with title "Claude Code" sound name "Ping"' 2>/dev/null
notify-send -u critical "Claude Code" "Claude needs your input" 2>/dev/null
printf '\a' >&2
if [ -n "$TMUX" ]; then
    tmux display-message "Claude Code: needs your input"
fi
if [ -n "$WSL_DISTRO_NAME" ]; then
    powershell.exe -Command "[System.Reflection.Assembly]::LoadWithPartialName('System.Windows.Forms'); [System.Windows.Forms.MessageBox]::Show('Claude needs your input','Claude Code')" 2>/dev/null &
fi
exit 0

curl -s -d "Claude Code needs your input" "https://ntfy.sh/your-topic" 2>/dev/null &
exit 0

{
  "hooks": {
    "Stop": [{
      "hooks": [{ "type": "command", "command": "bash ~/.claude/hooks/early-notify.sh" }]
    }]
  }
}

The Stop hook fires immediately when Claude finishes — no 60-second delay. You get the notification right away, whether you're in another window, on your phone (via ntfy/Slack), or in another tmux pane.
For ADHD-friendly workflows: combine the Stop hook notification with a terminal bell (\a) which many terminals flash in the taskbar/dock.

karlhorky · 2 months ago

@MosheBenZacharia in comment #4009049985: add this to your ~/.CLAUDE.json > "messageIdleNotifThresholdMs": 5000, (this is 5 seconds)

@MosheBenZacharia thanks for that!

I can confirm this on my side (June 2026):

Claude Code searched its source in the Bun-compiled executable claude.exe, and this appears to be the correct (undocumented!) setting:

Close Claude Code (it writes to ~/.claude.json on exit)
Open ~/.claude.json
Add the following line at the top level of the JSON object to configure the number of milliseconds to prompt the user after idle (below is instant, 2000 would be 2s):

``json "messageIdleNotifThresholdMs": 0,``

ajdinmore · 1 month ago

To doubly confirm: messageIdleNotifThresholdMs is correct.

Claude may claim it isn't - despite being able to identify it from examining the executable - as it's not listed in the settings.json schema and so rejected by the settings validator. It needs to be added there, along with anywhere Claude checks for reference on its own settings.