`Notification` hook causes repeating sound every ~60s after turn completes (Claude Code `idle_prompt`)

[yusufkinatas]

Observed behavior

After Claude Code finishes a turn, peon-ping plays the task.complete sound once (correct), but then keeps re-playing it roughly every 60 seconds until I focus the terminal. I want exactly one sound per completion.

Root cause (from reading peon.sh)

The default install binds peon-ping to Claude Code's Notification hook. Claude Code re-fires this hook with notification_type = "idle_prompt" every ~60s while the terminal is unfocused and Claude is awaiting user input. In peon.sh around lines 4260-4270, idle_prompt is routed to category task.complete and a sound is played on every fire:

elif ntype == 'idle_prompt':
    category = 'task.complete'
    ...
    notify = '1'

Because the Stop hook also routes to task.complete (once), users end up with: one sound from Stop + an unbounded repeat loop from idle_prompt firings.

Workaround

Remove the Notification hook binding for peon.sh from ~/.claude/settings.json. Keeps Stop (one-shot completion sound) and PermissionRequest (separate hook) working, loses sound on rare elicitation_dialog events.

Questions

1. Is the current behavior intentional, or should idle_prompt be deduplicated (e.g., play at most once per idle state, or skipped if a Stop-triggered task.complete already fired in the last N seconds)?
2. Could the default installer skip binding Notification for Claude Code, or add a config flag like suppress_idle_prompt_repeats: true?
3. Are categories.task.complete users expected to differentiate Stop-fired completion from idle_prompt-fired completion? Those feel like semantically different events.

Environment

• peon-ping 2.20.0
• macOS 26.3.1 (Tahoe)
• Claude Code

[kibermaks]

It's probably that you have CodexBar or similar tools that show remaining quota. By default, it checks every minute what matches your observation.
In the last version of peon-ping, you can set exclude_dirs in the config.
check https://github.com/PeonPing/peon-ping#per-ide-pack-assignment-ide_rules

[garysheng]

Confirming the diagnosis, you're reading peon.sh correctly. idle_prompt is intentionally routed to task.complete so users still get a notification when Claude Code asks for input but the terminal is unfocused. The bug is that we don't dedupe against an already-fired Stop, so on every 60-second re-poke the same sound replays.

The right fix is on our side, two pieces:

1. Track the most recent task.complete fire per session in .state.json (we already track last_stop for debouncing, this would just extend it). On Notification with idle_prompt, suppress if a task.complete for the same session fired within a configurable window.
2. Add suppress_idle_prompt_repeats: true (default true) as the config knob, since some users may actually want the periodic nudge.

To answer your three questions directly:

1. Not intentional, the repeats are the bug.
2. We should keep binding Notification because it also carries elicitation_dialog and other types you'd want sounded. The fix belongs in the routing logic, not the install step.
3. Stop and idle_prompt are semantically different (terminal focus state, not completion semantics). The routing collapse to task.complete was a convenience that's now hurting more than it helps. Long-term we may want a separate task.idle_reminder CESP category.

Workaround you found (drop the Notification binding) is a fine stopgap until this lands. PR welcome if you want to take it, otherwise I'll prioritize given the ergonomic damage.