Feature Request: Add `PermissionResponse` hook event triggered after user responds to permission prompt

Summary

There is currently no hook event that fires after a user responds (allow/deny) to a permission prompt. PermissionRequest fires when the prompt appears, but there is no corresponding event when the user completes their response. This asymmetry leaves the permission lifecycle incomplete — there is an "open" but no "close."

Motivation

PermissionRequest lets hooks react when Claude starts waiting for permission. But without a corresponding PermissionResponse, any state set up during that phase cannot be reliably cleaned up. This blocks several useful patterns:

1. State Cleanup (visual indicators, notifications, etc.)

Any "waiting" state set during PermissionRequest has no reliable teardown point:

• Terminal tab color / title changes
• Desktop notification badges
• IDE status bar indicators
• Sound alerts

2. Audit Logging

No way to record what the user actually decided:

• Which tool was allowed/denied, and when
• Security audit trails in team environments
• Compliance tracking for sensitive operations

3. Conditional Follow-up Actions

Cannot trigger different workflows based on the decision:

• Deny → send Slack/Discord alert ("Claude was blocked, needs attention")
• Allow → run a pre-execution setup script
• Deny → suggest alternative approaches via context injection

4. Permission Response Time Metrics

Cannot measure the PermissionRequest → response duration:

• Identify workflow bottlenecks (which prompts slow users down?)
• Optimize hook configurations based on actual usage patterns

Why PostToolUse is insufficient:

1. Deny case: If the user denies, no hook fires at all — any "waiting" state persists forever.
2. Timing: Even on allow, PostToolUse fires after tool execution completes, not when the user responds. For long-running commands, the gap can be significant.

Proposal

Add a PermissionResponse hook event that fires immediately after the user responds to a permission prompt, completing the permission lifecycle.

Suggested input payload:

{
  "session_id": "abc123",
  "hook_event_name": "PermissionResponse",
  "tool_name": "Bash",
  "tool_input": {
    "command": "rm -rf node_modules",
    "description": "Remove node_modules directory"
  },
  "response": "allow"
}

Key fields:

• response: "allow" | "deny" — what the user chose
• tool_name / tool_input: same as PermissionRequest, for correlation

Example: Terminal Tab Color Indicator

// ~/.claude/settings.json
{
  "hooks": {
    "PermissionRequest": [{
      "matcher": "",
      "hooks": [{
        "type": "command",
        "command": "echo -ne '\\e]6;1;bg;red;brightness;255\\a'"
      }]
    }],
    // 👇 Currently not possible
    "PermissionResponse": [{
      "matcher": "",
      "hooks": [{
        "type": "command",
        "command": "echo -ne '\\e]6;1;bg;*;default\\a'"
      }]
    }]
  }
}

Alternatives Considered

| Approach | Problem |
|----------|---------|
| Use PostToolUse to restore | Doesn't fire on deny; fires too late on allow |
| Use Notification with matcher | Read-only, cannot detect response completion |
| Poll/timer in PermissionRequest hook | Hacky, unreliable, no way to detect when prompt is dismissed |

None of these alternatives can reliably detect the moment a user finishes responding to a permission prompt.

Design Consistency

The current hook system already follows a symmetric pattern for tool execution (PreToolUse / PostToolUse). Adding PermissionResponse would bring the same symmetry to the permission lifecycle:

| Lifecycle | Open | Close |
|-----------|------|-------|
| Tool execution | PreToolUse | PostToolUse ✅ |
| Permission prompt | PermissionRequest | missing ❌ |
| Permission prompt (proposed) | PermissionRequest | PermissionResponse ✅ |