[BUG] "Response completions" macOS notifications don't fire despite correct settings

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Summary

The Response completions notification toggle in the Claude desktop app is ON, and macOS notification permissions for Claude are fully granted (Allow ON, Alert Style Persistent, Desktop/Notification Center/Lock Screen all checked, Badge ON). Despite this, no banner appears when a Claude response finishes. No error surfaces to the user.

Environment

• App: Claude desktop app (Anthropic-published macOS app, including Claude Code surfaces)
• OS: macOS
• Relevant macOS settings for Claude:
• Allow notifications: ON
• Alert Style: Persistent
• Desktop / Notification Center / Lock Screen: all checked
• Badge application icon: ON
• Play sound for notification: OFF
• Summarize notifications: ON
• Relevant in-app settings (all ON):
• Response completions
• Emails from Claude Code on the web
• Dispatch messages
• Model in use: Opus 4.7 (1M)

Steps to reproduce

1. Open Claude desktop app with the settings above.
2. Start a long-running task (one that takes >30s so you can walk away).
3. Switch focus to another app (to rule out foreground suppression).
4. Wait for the response to complete.

Expected

A banner appears announcing the response is complete, using the Persistent alert style configured for Claude.

Actual

No banner appears. The task completes silently. Notification Center does not accumulate missed alerts from Claude either.

Diagnostic isolation test (macOS delivery is NOT the problem)

Running this in Terminal does produce a visible banner:

osascript -e 'display notification "test" with title "Claude"'

This banner is attributed to Script Editor, not Claude. Its successful delivery rules out:

• Focus / Do Not Disturb blocking
• System-level notification permission issues
• Notification daemon failure

The problem is therefore isolated to the Claude app's notification-emit path (or a classification that causes macOS to route them away from immediate display).

Hypotheses (not confirmed by official docs)

1. Summarize notifications bundling. If Claude's response-completion alerts are classified as non-time-sensitive, macOS may be batching them into Scheduled Summaries rather than firing them immediately. Anthropic documentation does not confirm whether Claude marks these alerts as time-sensitive.
2. Claude app is not actually emitting the notification. The in-app toggle may be cosmetic in the current build, or response-completion events may not be wired to the notification pipeline.
3. Foreground-app suppression. Apple's docs state the system silences notifications for the foreground app by default. If Claude was frontmost when the response completed, no banner fires. Mitigated by steps above (focus switched to another app before completion) but worth confirming the app's notification presentation behavior for this case.

Workaround

A Claude Code user-level Stop hook using osascript reliably fires a banner every time a turn ends:

{
  "hooks": {
    "Stop": [{
      "hooks": [{
        "type": "command",
        "async": true,
        "command": "d=$(basename \"$PWD\"); osascript -e \"display notification \\\"Task complete in $d\\\" with title \\\"Claude Code\\\" sound name \\\"Bottle\\\"\""
      }]
    }]
  }
}

Caveat: these banners are attributed to Script Editor (not Claude), so Claude's own notification style doesn't apply to them — the user has to configure Script Editor's alert style to Persistent separately. This is an annoying coupling and not a substitute for the app fixing its own notification path.

Severity

Medium. The core product behavior (notifying the user when a task is ready for them) is silently broken for users who think they've configured it correctly. The failure mode is invisible — users don't know they're missing alerts until they check and find old completed responses waiting.

Suggested investigation

1. Confirm whether the Claude desktop app's response-completion events are wired to UNUserNotificationCenter / NSUserNotification at all, and whether the toggle state is checked.
2. If they are wired, confirm whether the notification request marks itself as time-sensitive / interruption-level .timeSensitive, so Summarize-notifications and Focus modes don't silently bundle it.
3. Consider adding an in-app Test notification button so users can isolate "the app isn't emitting" from "macOS is silencing" without resorting to osascript from Terminal.
4. If the app is emitting correctly, document the interaction with macOS Summarize notifications — users will reasonably expect "Alert Style: Persistent" to mean immediate-and-sticky, not "bundled into 9 AM summary."

Related

• No open issue matching this exact symptom in anthropics/claude-code as of filing.
• Adjacent issues: #45962 (Dispatch offline), #48276 (crash on macOS 26.3.1+), #47522 (empty sidebar).

What Should Happen?

Expected

A banner appears announcing the response is complete, using the Persistent alert style configured for Claude.

Error Messages/Logs

Steps to Reproduce

Steps to reproduce

1. Open Claude desktop app with the settings above.
2. Start a long-running task (one that takes >30s so you can walk away).
3. Switch focus to another app (to rule out foreground suppression).
4. Wait for the response to complete.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

Claude 1.3109.0 (35cbf6) 2026-04-16T20:32:01.000Z

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_