[BUG] Monitor Tool Notification Flooding in Poll Loops

Resolved 💬 3 comments Opened Apr 18, 2026 by luarworld Closed May 31, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

When the Monitor tool is used in a polling loop pattern (check condition, sleep, repeat until done), it emits one notification event per poll iteration including all intermediate "not done yet" states. This produces notification spam that drowns out the terminal event.

What Should Happen?

  • Monitor emits notifications only for terminal or significant events (completion, failure, timeout)
  • Intermediate status updates do NOT flood the notification channel
  • Documentation clearly explains which events trigger notifications
  • Optional filtering mechanism to suppress non-terminal state emissions

this also started on 2.1.112, I upgraded to 2.1.114 and same issue.

Error Messages/Logs

- Monitor emits one notification per stdout line received
- In a poll loop, this means one notification per iteration, including all "still processing" states
- The terminal event is buried in a stream of intermediate status messages
- UX is degraded by notification spam

Steps to Reproduce

  1. Implement a polling pattern: loop until a condition is met, with Monitor checking output each iteration
  2. Use a short sleep interval (e.g., 5 seconds) between checks
  3. Monitor a long-running operation (e.g., 30-second job)
  4. Observe notifications arriving for every iteration
  5. Result: ~6 notifications for intermediate states before the final completion event

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.109

Claude Code Version

2.1.114

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Non-interactive/CI environment

Additional Information

  • Poor user experience: users see many notifications about an operation still in progress
  • Notification channels can become unusable for actual actionable events
  • Discrepancy between documentation ("notifications arrive when you keep working") and reality ("notifications arrive every 5 seconds")
  • Users must manually implement stdout filtering to suppress intermediate states

Honestly these last versions are so buggy with loops, I just stopped using it now.

View original on GitHub ↗

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