[BUG] Hook Regression in 2.0.17-2.0.22 - UI Shows Duplicate Messages for Stop, UserPromptSubmit, SessionStart (worked in 2.0.15)

Additional Testing

Confirmed this regression reproduces across multiple terminal emulators:

• iTerm2 (latest): Stop hook fires 3-4 times ❌
• Ghostty (1.2.2): Stop hook fires 3-4 times ❌

This confirms the issue is in Claude Code 2.0.17 itself, not terminal-specific.

Terminal Versions Tested

• iTerm2: Latest stable release
• Ghostty: 1.2.2 (stable channel, build mode: ReleaseFast)
• macOS: Darwin 25.0.0

The behavior is consistent across all terminals - hooks execute multiple times with the same PPID, suggesting a race condition or duplicate event emission in the Claude Code hook system.

Severity Update: Progressive Duplication

The duplication gets progressively worse during a session:

Observed Behavior in 2.0.17

From a single response, the stop hook fired 13 times:

⎿  Stop hook succeeded:
⎿  Stop hook succeeded:
⎿  Stop hook succeeded:
⎿  Stop hook succeeded:
⎿  Stop hook succeeded:
⎿  Stop hook succeeded:
⎿  Stop hook succeeded:
⎿  Stop hook succeeded:
⎿  Stop hook succeeded:
⎿  Stop hook succeeded:
⎿  Stop hook succeeded:
⎿  Stop hook succeeded:
⎿  Stop hook succeeded:

This is progressive duplication - the same behavior as the previously fixed issue #3523. The number of hook executions increases over the session lifetime.

Comparison

• 2.0.15: 1 execution (correct) ✅
• 2.0.17: 3-4 executions initially, escalating to 13+ executions ❌

This severely impacts usability:

• 13 notification sounds playing simultaneously
• 13 speech synthesis processes saying "Done with..."
• Significant performance degradation
• Makes the hook system unusable in long sessions

This is the exact same progressive duplication pattern from #3523, which suggests the fix was lost during a refactor or merge.

Thanks for raising this. I noticed my stop hook notifications were going crazy since the update. This explains it.

It is a direct accumulation of previous stop hooks. No idea HOW this kind of thing could happen. It literally has to be storing the previous json responses. I have a systemMessage in my Stop hook and each message shows the token usage. After each Stop I get ALL the other stop systemMessages(with their original token usage values) and then the new one. It accumulates DIRECTLY with EACH AND EVERY Stop hook. Seriously guys, you need to STOP relying on Claude code writing and validating your code. IT LOVES to restore old regressions because it DOESNT DELETE CODE. It ends up find that old code it "took out" at some point in the future and thinks "this should be added back in" derp derp. You need to CLEAN OUT ALL YOUR DEAD CODE SO THIS KIND OF GARBAGE REVERSION CAN'T HAPPEN. There is ZERO chance of a exact duplication of an old regression UNLESS YOU FAILED TO CLEAR OUT THE OLD DEAD CODE.

The more this happens the more it seems you guys are just VIBE coding Claude Code. Get your act together. This is just pitiful.

Still reproduces in fresh 2.0.20, but seemingly with a bit lesser frequency, but can still get to 10 repetitions.

v. 2.0.20
I've observed the same issue, but it's not that the hook itself is firing multiple times. It's that the hook output is rendering multiple times. I run a script that simply logs the JSON input when the hook triggers, and I'm only getting one log per call. However, if I turn on my verbose logging which outputs details to the terminal (via systemMessage), my terminal becomes littered with systemMessages that repeat on every, single, hook.

same here 🥹

same here, but I've seen it happen with SessionStart and UserPromptSubmit hooks as recently as today. They would both trigger two, if not more times.

same in fresh 2.0.21 - accumulated to 5 now in the same session

I can confirm the same accumulation behavior affects UserPromptSubmit hooks (in addition to the Stop hooks described here).

Environment

• Version: Claude Code 2.0.21
• OS: macOS (Darwin 25.1.0)
• Hook Type: UserPromptSubmit

Symptom

Same progressive accumulation pattern as Stop hooks:

• 1st prompt: Hook fires 1x ✅
• 2nd prompt: Hook fires 2x
• 3rd prompt: Hook fires 3x
• 4th prompt: Hook fires 4x
• 5th prompt: Hook fires 5x
• ...and so on

Hook Configuration

{
  "hooks": {
    "UserPromptSubmit": [
      {
        "matcher": "*",
        "hooks": [
          {
            "type": "command",
            "command": "~/.claude/hooks/user-prompt-submit.sh",
            "timeout": 2
          }
        ]
      }
    ]
  }
}

Hook Script Example

#!/usr/bin/env bash
set -euo pipefail

main() {
    echo "AGENT & SKILL SELECTION REMINDER:"
    echo "- Agent selection: haiku (fast/cheap), sonnet (standard), opus (complex)"
    echo "- Skills auto-invoke based on file types and keywords"
    echo "- Use Task tool for multi-step work; never use skill names as subagent_type"
    echo "- Review ./.claude/CLAUDE.md for complete guidelines"
}

main "$@"

The hook script outputs plain text (exit code 0), which should be injected once per prompt, but instead accumulates with each submission.

---

This suggests the 2.0.17+ regression affects multiple hook types (Stop, UserPromptSubmit, and likely others), not just Stop hooks specifically.

Configuration Analysis: Stop Hook Bug is Not User-Caused

I've analyzed my complete Claude Code setup to determine if my configuration could be causing the duplicate message bug. Conclusion: My setup cannot cause this issue.

Evidence: Hook Executes Only Once

Log entries from my stop hook show single execution per response:

[STOP HOOK] Running at Fri Oct 17 21:28:16 EDT 2025 - PID:47982 PPID:18583 PWD:~/.../project

No duplicate log entries = hook fires once, but UI shows 4-7 duplicate messages.

My Hook Configuration

settings.json - Standard configuration:

{
  "hooks": {
    "Stop": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "~/.claude/stop-hook.sh"
          }
        ]
      }
    ]
  }
}

stop-hook.sh - Has deduplication logic (added for old bugs #3465, #3523):

#!/bin/bash
# Timestamp-based deduplication
NOW=$(date +%s)
LOCK_FILE="/tmp/claude-stop-hook-$PPID.lock"
LOCK_TTL=3  # seconds

if [ -f "$LOCK_FILE" ]; then
    LOCK_TIME=$(cat "$LOCK_FILE" 2>/dev/null || echo 0)
    TIME_DIFF=$((NOW - LOCK_TIME))
    if [ "$TIME_DIFF" -lt "$LOCK_TTL" ]; then
        echo "[STOP HOOK] Skipping duplicate" >> "$LOG_FILE"
        exit 0
    fi
fi
echo "$NOW" > "$LOCK_FILE"

# ... rest of hook logic (notifications, etc)

Result: Lock file deduplication never triggers - no "Skipping duplicate" messages in logs, proving hook fires only once.

Why This Proves It's a Claude Code UI Bug

1. Hook executes 1x (proven by logs) → UI renders 4-7x (visible output)
2. Lock mechanism never activates → No actual duplicate executions
3. Bug persists across versions 2.0.17-2.0.22 → Not configuration-dependent
4. Same behavior in multiple terminals (iTerm2, Ghostty) → Not terminal-specific
5. Workaround is downgrading (2.0.15 works perfectly) → Regression in Claude Code itself

Additional Notes

• UserPromptSubmit hook also configured (Python script, clean exit, no stdout)
• Custom statusLine command configured (unrelated to Stop hook)
• No unusual permissions or settings
• Bug appears identical whether using npx or installed version

The duplication occurs in Claude Code's output rendering layer, not in hook execution. My configuration is clean and cannot cause this issue.

Tested 2.0.22 (released 2025-10-17): Bug still present - same UI duplication behavior.

looks like not reproducing in 2.0.24. I'll watch next release too.

I confirm it doesn't happen in 2.0.24, however the message is totally
ignored :/

On Tue, Oct 21, 2025 at 12:04 AM kuz8 @.***> wrote:

kuzmeech left a comment (anthropics/claude-code#9602) <https://github.com/anthropics/claude-code/issues/9602#issuecomment-3425049846> looks like not reproducing in 2.0.24 — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/9602#issuecomment-3425049846>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAABTCKD7QPMUG2DRKTU64D3YXLGJAVCNFSM6AAAAACJJMI476VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTIMRVGA2DSOBUGY> . You are receiving this because you were mentioned.Message ID: @.***>

I believe this particular issue is fixed for me - will continue to monitor for now.

Also looks fixed in 2.0.25

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.