### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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? Task completion notifications from the Claude desktop app stopped appearing on macOS. Both the visual banner and the sound are gone. This is a regression:

[BUG] Notification subsystem stops initialising on macOS — regression in 1.28929.0

Status Open

Maintainer reply None cached

Activity 0 comments · opened Aug 16, 2026

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?

Task completion notifications from the Claude desktop app stopped appearing on
macOS. Both the visual banner and the sound are gone. This is a regression:
they worked reliably before, and no macOS settings were changed on my side.

The problem is not limited to Cowork — no notification is emitted at the end of
a regular chat response either. Log analysis narrows the regression to build
1.28929.0.

Closest existing issue: #50480 (same symptom, closed as duplicate).
Possibly related: #69408 / #41511 (macOS notifications routed through osascript).

Environment

Claude desktop app: 1.30096.5 (6e1346), built 2026-08-14T21:58:49Z
macOS: Tahoe 26.5.2 (25F84), Apple Silicon
Plan: Pro

Already ruled out

"Response completions" toggle is ON in the app settings.
System Settings, Notifications, Claude: Allow ON, alert style set, banners,

sound, badge, Notification Center and Lock Screen all enabled.

System Settings, Notifications, Script Editor: fully enabled as well

(relevant because notifications are emitted via osascript).

Scheduled Summary disabled for both. No Focus mode active.
App fully quit with Cmd+Q and relaunched; machine restarted.
Also tested on the Claude mobile app with the same account: no push

notification on task completion either.

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

produces a banner correctly. This rules out system-level permissions, Focus
modes and a broken notification daemon: the delivery path itself works.

swift.log is still being actively written (latest entries today, normal

startup sequence), so this is not log rotation or a logging failure. The
notification subsystem no longer initialises at all: no emission attempts,
no delivery-failure entries. It is entirely silent.

macOS ruled out

system_profiler SPInstallHistoryDataType shows macOS 26.5.2 was installed on
2026-06-29, six weeks before the failure (previous updates: 26.5 on 2026-05-13,
26.5.1 on 2026-06-03). No OS update anywhere near the failure window.

App update history (from the updater log)

2026-07-28 08:10  1.22209.3  -> 1.24012.9
2026-08-03 21:20  1.24012.9  -> 1.24012.11
2026-08-05 17:01  1.24012.11 -> 1.25927.0
2026-08-08 23:15  1.25927.0  -> 1.26832.0
2026-08-13 16:52  1.26832.0  -> 1.28929.0     <-- regression
2026-08-14 01:22  1.28929.0  -> 1.30096.1
2026-08-16 05:44  1.30096.1  -> 1.30096.5     (current, still broken)

Narrowing down the regression

[Fonts] is written at every app launch; [Notifications] is written some
minutes later, once the notification subsystem initialises. Measured gaps
between the two over the preceding week range from 4 to 74 minutes
(minimum: 2026-08-11 06:43:18 to 06:47:20).

Launches around the failure window:

2026-08-12 01:37:53  launch on 1.26832.0  -> [Notifications] at 01:45:51 (+8m)
2026-08-13 16:51:33  launch on 1.26832.0  -> none (session lasted 55 seconds)
2026-08-13 16:52:27  update 1.26832.0 -> 1.28929.0 installed
2026-08-13 16:52:28  launch on 1.28929.0  -> none
every launch since, through 1.30096.5    -> none

The 16:51:33 session was terminated by the update 55 seconds later, well below
the 4-minute minimum gap observed, so it could not have reached the
initialisation point. Its lack of an entry is not evidence of failure.

Caveat, stated for completeness: a few earlier launches also produced no
[Notifications] entry (2026-08-06 05:02 and 06:04, 2026-08-10 00:11 and
17:57), presumably short sessions for the same reason. The evidence is not any
single absence but the sustained one: at least one entry on nearly every day
through 12 August, then zero across four days of heavy daily use.

Last confirmed working launch: 2026-08-12 01:37:53 on 1.26832.0
First confirmed broken launch: 2026-08-13 16:52:28 on 1.28929.0

Additionally, main-window.log and mcp.log were both truncated to 0 bytes at
2026-08-13 16:52, the same minute 1.28929.0 was installed, and have not been
written to since, while all other log files remain current.

Regression introduced in 1.28929.0, persisting through 1.30096.1 and 1.30096.5.

What Should Happen?

When a Cowork task completes, or a chat response finishes, the desktop app
should emit a macOS system notification (visual banner plus sound), as it did
through build 1.26832.0.

More specifically: the notification subsystem should initialise after app
startup and log its authorization check, as it did on every launch up to
2026-08-12. Since 1.28929.0 that initialisation no longer happens at all, so
no notification is ever attempted.

Error Messages/Logs

$ grep -i notif ~/Library/Logs/Claude/swift.log | tail -5
[Notifications] 2026-08-11 04:43:41 [info] Authorization granted: true
[Notifications] 2026-08-11 06:47:20 [info] Authorization granted: true
[Notifications] 2026-08-11 18:31:28 [info] Authorization granted: true
[Notifications] 2026-08-12 01:45:51 [info] Authorization granted: true
(nothing after this date, across four days of daily use)

$ tail -3 ~/Library/Logs/Claude/swift.log
[Hotkey] 2026-08-16 09:49:50 [info] No accessibility permissions, using basic hotkey detection
[Fonts] 2026-08-16 09:49:50 [info] Loaded 4/4 fonts from /Applications/Claude.app/Contents/Resources/fonts
[NAPI] 2026-08-16 09:49:51 [info] Memory pressure monitor subscribed

No error is logged anywhere. The subsystem simply never initialises.

Steps to Reproduce

Install Claude desktop app 1.28929.0 or later on macOS (reproduced on

Tahoe 26.5.2, Apple Silicon).

Verify notifications are permitted: app settings, "Response completions" ON;

System Settings, Notifications, both Claude and Script Editor fully enabled;
no Focus mode active.

Start a Cowork task that takes at least 30 seconds, or send any chat message

that produces a reasonably long response.

Switch to another application before it completes, so the app is not in the

foreground (macOS suppresses banners for the frontmost app).

Wait for the task or response to finish.

Result: no banner, no sound, no missed alert in Notification Center.

To confirm the underlying cause, leave the app running for at least 10 minutes
after launch, then run:

grep -i notif ~/Library/Logs/Claude/swift.log | tail

No [Notifications] entry is written, whereas builds up to 1.26832.0 logged
"Authorization granted: true" a few minutes after every launch.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

1.26832.0

Claude Code Version

Claude desktop app 1.30096.5 (6e1346), built 2026-08-14T21:58:49Z — not Claude Code CLI

Platform

Other

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Supersedes #87099 (closed by me; this is a cleaner rewrite).

View original on GitHub ↗