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

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?

Preflight Checklist

• [x] I have searched existing issues (closest match: #50480, closed as duplicate)
• [x] This is a single bug report
• [x] I am using the latest version of the Claude desktop app

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 (below) narrows the regression to
build 1.28929.0.

Environment

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

Steps to Reproduce

1. Start a Cowork task that takes at least 30 seconds.
2. Switch to another application before it completes (to rule out

foreground-app notification suppression).

1. Wait for the task to finish.

Expected Behaviour

A system notification with sound appears when the task completes.

Actual Behaviour

The task completes silently. No banner, no sound, and no missed alert in
Notification Center.

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 — see #69408 / #41511).

• 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.

Additional Diagnostics

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

banner appears correctly. Rules out system-level permissions, Focus modes and
a broken notification daemon — the delivery path itself is functional.

• ~/Library/Logs/Claude/swift.log

The only notification-related entries in the logs are authorization checks of
the form:
[Notifications] 2026-08-11 06:47:20 [info] Authorization granted: true
They are dense and regular from late June through 2026-08-12 01:45:51.
After that date: not one.

swift.log is still being actively written — the most recent entries are from
today (2026-08-16 09:49, normal startup sequence: Hotkey, Fonts, NAPI), and
the app has been launched and used heavily every day since 12 August. This is
not log rotation or a logging failure: the notification subsystem no longer
initialises at all. There are no emission attempts and no delivery-failure
entries anywhere in the logs — it is entirely silent.

Timeline

• 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 minutes to 74 minutes (min: 2026-08-11
06:43:18 -> 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 here 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.

Related Issues

• #50480 — same symptom, closed as duplicate
• #69408 / #41511 — macOS notifications routed through osascript

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 at 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 — 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. The subsystem simply never initialises.

Steps to Reproduce

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

Tahoe 26.5.2, Apple Silicon).

1. Verify notifications are permitted: app settings → "Response completions"

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

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

that produces a reasonably long response.

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

foreground (macOS suppresses banners for the frontmost app).

1. Wait for the task or response to finish.

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

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

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

Claude Desktop

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_