claude-code - 💡(How to fix) Fix "Waiting for input" notification fires on Windows when Claude is not waiting for input [1 comments, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#58753Fetched 2026-05-14 03:40:22
View on GitHub
Comments
1
Participants
1
Timeline
5
Reactions
0
Timeline (top)
labeled ×4commented ×1

On Windows, Claude Code fires a "session waiting for input" toast notification at the end of every assistant turn, including turns that end with a status message rather than a question or prompt. There is no input pending — Claude has just posted output — yet the notification still fires.

Root Cause

On Windows, Claude Code fires a "session waiting for input" toast notification at the end of every assistant turn, including turns that end with a status message rather than a question or prompt. There is no input pending — Claude has just posted output — yet the notification still fires.

Fix Action

Fix / Workaround

Workarounds attempted (none viable for this case)

  • Notification hook event with {"continue": false} — confirmed via diagnostic logging that the Notification event does NOT dispatch for these idle/turn-end alerts. UserPromptSubmit fires correctly; Notification never fires. So local hooks cannot suppress this notification.
  • preferredNotifChannel: "notifications_disabled" — works, but is global to all Claude Code sessions on the machine. There is no session-scoped equivalent, so silencing the loop session also silences genuine notifications from other concurrent sessions.
  1. Suppress "waiting for input" notifications when the assistant turn does not actually wait on user input (no question, no permission prompt, no idle gating).
  2. Dispatch the Notification hook event for these alerts so users can suppress them via a hook (e.g., based on prompt fingerprint or session state).
  3. Add a session-scoped or hook-output way to suppress the alert for a specific turn.
RAW_BUFFERClick to expand / collapse

Summary

On Windows, Claude Code fires a "session waiting for input" toast notification at the end of every assistant turn, including turns that end with a status message rather than a question or prompt. There is no input pending — Claude has just posted output — yet the notification still fires.

Repro

  1. On Windows 11, set up a recurring /loop (e.g. /loop 10m /dothatthing) where each iteration completes with a short status summary and no user-facing question.
  2. Each time the cron fires and Claude finishes posting its status update, a Windows toast notification appears claiming the session is waiting for input.
  3. Nothing is actually waiting — the next action is the next cron fire, not a user reply.

Expected

The "waiting for input" notification should fire only when Claude is genuinely blocked on user input (a permission prompt, an explicit question, an idle pause after work the user must respond to). It should not fire on every assistant turn ending.

Actual

Notification fires after every turn ending, including pure status updates from autonomous loop iterations. This makes long-running /loop workflows noisy and trains the user to ignore the alert — defeating its purpose.

Workarounds attempted (none viable for this case)

  • Notification hook event with {"continue": false} — confirmed via diagnostic logging that the Notification event does NOT dispatch for these idle/turn-end alerts. UserPromptSubmit fires correctly; Notification never fires. So local hooks cannot suppress this notification.
  • preferredNotifChannel: "notifications_disabled" — works, but is global to all Claude Code sessions on the machine. There is no session-scoped equivalent, so silencing the loop session also silences genuine notifications from other concurrent sessions.

Suggested fixes (either would help)

  1. Suppress "waiting for input" notifications when the assistant turn does not actually wait on user input (no question, no permission prompt, no idle gating).
  2. Dispatch the Notification hook event for these alerts so users can suppress them via a hook (e.g., based on prompt fingerprint or session state).
  3. Add a session-scoped or hook-output way to suppress the alert for a specific turn.

Environment

  • OS: Windows 11 Enterprise 10.0.26200
  • Shell: PowerShell 5.1 / Git Bash
  • Claude Code: Opus 4.7

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING