Repository navigation
PermissionRequest hook fires for every tool check, not just when actually blocked #29212
Description
Problem
The PermissionRequest hook fires on every tool permission check, even when the tool is auto-allowed and no user interaction is required. This makes it unusable for triggering alerts (sounds, notifications, window focus) that should only fire when Claude is actually blocked and waiting for user input.
Expected Behavior
PermissionRequest hook should only fire when Claude is actually paused and waiting for the user to approve or deny a permission — i.e., when user interaction is genuinely required.
Actual Behavior
PermissionRequest fires continuously for every tool use, regardless of whether the tool is auto-allowed or blocked. This causes any notification tied to this hook (e.g., a sound alert) to trigger repeatedly and unexpectedly throughout normal operation.
Use Case
I wanted to set up an audio notification so that when Claude Code is waiting for permission, a sound plays every 5 seconds to grab my attention (especially useful when working across multiple windows or apps).
settings.json hook config:
"PermissionRequest": [
{
"matcher": "",
"hooks": [
{
"type": "command",
"command": "nohup /path/to/permission_sound.sh &>/dev/null &"
}
]
}
]This fired constantly during normal tool use, making it unusable.
Suggested Fix
Either:
- Only fire
PermissionRequesthook when the request is actually blocking (user input required), or - Pass a field in the hook's JSON input (e.g.,
"blocked": true/false) so the hook script can decide whether to act
Environment
- OS: macOS Darwin 25.3.0
- Claude Code version: latest
Activity
github-actions commentedon Feb 27, 2026
Found 2 possible duplicate issues:
permission_promptevents with no visible permission dialog #16102AskUserQuestionis used,PermissionRequesthook is triggered. #15400This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
sstklen commentedon Feb 27, 2026
The
PermissionRequesthook currently fires on every permission check, not just when user interaction is actually required. The distinction between "permission was evaluated (auto-allowed)" and "permission requires user input" isn't exposed in the current hook architecture.First step: Check what your hook actually receives on stdin — the payload structure determines whether a filter is possible:
If the payload includes a field that distinguishes pending-user-input from auto-allowed (like a
decisionorbehaviorfield), you can gate your notification on that.If no such field exists in the payload, then the current hook architecture doesn't support this use case — what you actually need is a separate hook event that only fires when Claude is genuinely paused waiting for approval. That would need to be a new hook type (something like
PermissionPendingorAwaitingApproval).Based on the behavior you're describing, this seems like the more likely scenario — worth confirming by inspecting the payload and then filing this as a feature request for a hook that only fires when user input is actually blocked.
Fix PermissionRequest notification flooding from subagent MCP tool calls
mydandyandy commentedon Mar 23, 2026
Session: Trinity (eb50) | Task: 6gF8v3VQVhrfhCgp
github-actions commentedon Apr 21, 2026
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
github-actions commentedon May 2, 2026
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.