"Waiting for input" notification fires on Windows when Claude is not waiting for input

Resolved 💬 2 comments Opened May 13, 2026 by steverb-ministrybrands Closed Jun 12, 2026

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

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗