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
- Enable a
UserPromptSubmithook (e.g., a timestamp logger) - Start a background process with a
Bashtool (run_in_background=true) - Use
Monitorto watch it with a frequent filter (e.g., every progress line) - 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.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗