Monitor tool events trigger UserPromptSubmit hooks, polluting conversation

Resolved 💬 3 comments Opened Apr 28, 2026 by echoplex17 Closed Apr 28, 2026

Summary

When using the Monitor tool to watch a background process, each Monitor event fires the UserPromptSubmit hook slot, making it appear as if the user submitted a new message.

Reproduction

  1. Enable a UserPromptSubmit hook (e.g., a timestamp logger)
  2. Start a background process with a Bash tool (run_in_background=true)
  3. Use Monitor to watch it with a frequent filter (e.g., every progress line)
  4. Observe: each Monitor event appears in the conversation as a new user-turn, with UserPromptSubmit hooks executing on each one

Observed behavior

[21:17 KST — rjh]          ← actual UserPromptSubmit hook (expected)
[1020/2060] 완료 (19.1s)   ← Monitor event (appears as user turn — unexpected)
[1021/2060] 20건 분류 중...

Each Monitor event generates a new conversation turn indistinguishable from a real user message, causing:

  • UserPromptSubmit hooks to fire for each Monitor event (timestamp logging, injection logic, etc.)
  • Conversation flow pollution
  • Inability to distinguish real user input from system notifications

Root cause hypothesis

Monitor events are routed through the same channel as user messages, triggering UserPromptSubmit hooks unintentionally.

Workaround

Narrow the Monitor grep filter to only match terminal events (completion, errors), minimizing hook firing frequency:

# Instead of matching every progress line, match only final states
grep -E "completed|FAIL|Error|⚠️"

Environment

  • Claude Code version: latest
  • Platform: macOS
  • Hook type: UserPromptSubmit (timestamp logger via remember plugin)

Expected behavior

Monitor events should not trigger UserPromptSubmit hooks. They should be distinguishable from actual user input both in the UI and in the hook execution layer.

View original on GitHub ↗

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