Desktop notifications fire inconsistently across responses in the same Code session

Description

In a single active Claude Code (desktop app, Code tab) session, desktop notifications fired inconsistently across consecutive assistant responses, with no pattern tied to response length, tool use, or content type.

Environment

• Claude Code desktop app, Code tab
• macOS (Darwin 23.1.0)
• Settings confirmed via in-app settings check:
• permission_request_notifications: banner (default)
• question_notifications: banner (default)
• task_complete_notifications: banner
• draw_attention_on_notifications: true
• notification_sound: system

Observed sequence (5 consecutive assistant responses, same open session)

1. Long response, multiple already-approved tool calls (Read/Edit/Write/Bash) — no notification
2. Short response using a tool not previously called in the session — notification received, but no visible permission-approval prompt was shown
3. Plain text response, zero tool calls — no notification
4. Plain text response, zero tool calls — no notification
5. Plain text response, zero tool calls — notification received

Expected

Notification behavior should be predictable from session settings and concrete events (new permission request, question prompt, or task completion while the app is backgrounded).

Actual

No correlation found between notifications and response length, tool novelty, or content type. Notably, response 5 (plain text, no tools) notified while two earlier plain-text responses with no tools did not — ruling out "new tool use" and "response complexity" as explanations.

Possible cause

May relate to the app window's focus/background state at the exact moment each response completes, but this isn't fully confirmed and doesn't obviously explain why two seemingly-identical plain-text responses behaved differently.