[BUG] Notification hook events missing `notification_type` field

Resolved 💬 3 comments Opened Nov 19, 2025 by terraboops Closed Jan 19, 2026

[BUG] Notification hook events missing notification_type field

Description

According to the Claude Code hooks documentation, Notification hook events should include a notification_type field to identify the type of notification being sent (e.g., permission_prompt, idle_prompt, auth_success, elicitation_dialog).

However, in practice, Notification events for permission prompts do not include the notification_type field.

Expected Behavior

Permission prompt Notification events should include:

{
  "hook_event_name": "Notification",
  "notification_type": "permission_prompt",
  "message": "Claude needs your permission to use Write",
  ...
}

Actual Behavior

Permission prompt Notification events are missing the notification_type field:

{
  "session_id": "c2080807-7e55-40ec-8134-9ec438bc5ec7",
  "transcript_path": "/home/terra/.claude/projects/-home-terra-Developer-navi/c2080807-7e55-40ec-8134-9ec438bc5ec7.jsonl",
  "cwd": "/home/terra/Developer/navi",
  "hook_event_name": "Notification",
  "message": "Claude needs your permission to use Write"
}

Steps to Reproduce

  1. Configure a Notification hook in ~/.claude/settings.json:
{
  "hooks": {
    "Notification": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "cat"
          }
        ]
      }
    ]
  }
}
  1. Trigger a permission prompt by requesting Claude to use a tool
  2. Observe the JSON output - notification_type field is missing

Impact

This makes it impossible to create hooks that respond differently to different types of notifications. For example, you cannot play different sounds for permission prompts vs. idle prompts vs. other notification types, as the documentation suggests is possible.

Environment

  • Claude Code version: (current as of 2025-11-19)
  • Platform: Linux (Arch Linux 6.17.8-hardened2-1-hardened)
  • Hook type: Notification

Workaround

Currently, the only workaround is to match on message content (e.g., checking if the message contains "permission"), which is fragile and not documented.

Related Documentation

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗