claude-code - 💡(How to fix) Fix Monitor tool events trigger UserPromptSubmit hooks, polluting conversation [2 comments, 2 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#54148Fetched 2026-04-28 06:37:57
View on GitHub
Comments
2
Participants
2
Timeline
7
Reactions
0
Timeline (top)
labeled ×4commented ×2closed ×1

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.

Error Message

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

Root Cause

Root cause hypothesis

Fix Action

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|⚠️"

Code Example

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

---

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

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.

extent analysis

TL;DR

Modify the Monitor grep filter to only match terminal events, reducing unnecessary UserPromptSubmit hook firings.

Guidance

  • Review the current grep filter used in the Monitor tool to ensure it's not too broad, causing excessive hook triggers.
  • Consider implementing a more specific filter, such as the suggested grep -E "completed|FAIL|Error|⚠️", to only capture final states or critical events.
  • Verify that the UserPromptSubmit hook is correctly configured to only execute on actual user input, not system-generated events like Monitor notifications.
  • Evaluate the possibility of introducing a distinct channel or flag for Monitor events to prevent them from being routed through the same channel as user messages.

Example

# Example of a narrowed grep filter
grep -E "completed|FAIL|Error|⚠️"

Notes

The provided workaround may not completely eliminate the issue but should reduce the frequency of unwanted UserPromptSubmit hook firings. Further investigation into the routing of Monitor events and user messages may be necessary for a comprehensive solution.

Recommendation

Apply the workaround by modifying the Monitor grep filter to minimize unnecessary hook triggers, as this is a straightforward and non-invasive approach to reduce the impact of the issue.

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…

FAQ

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.

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix Monitor tool events trigger UserPromptSubmit hooks, polluting conversation [2 comments, 2 participants]