[BUG] Claude Desktop never registers with macOS Notification Center — no entry in System Settings, persists after reinstall + tccutil reset (macOS 26.6 beta)

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?

Note: This concerns the Claude Desktop app (macOS), not the Claude Code CLI — filing here as the closest active tracker.

The core problem: Claude never appears in System Settings → Notifications at all — not even a disabled/"never asked" entry. Because there is no entry, notification behavior cannot be configured, and macOS never records a permission grant or denial for the app. This is one layer upstream of, and distinct from, the known completion-notification issues (see below): those assume an app that is already registered and permission-granted; this bug is that the app never registers in the first place.

The "Response completions" in-app notification toggle is on (along with Code 알림 / Code 권한 요청 / 메시지 전송), yet no "Claude" entry ever registers in System Settings. This persists after a full uninstall + reinstall, and after tccutil reset All com.anthropic.claudefordesktop followed by a fresh relaunch.

The bundled main-log.txt shows NotificationService initialized with UNUserNotificationCenter (macOS) on every launch, but no subsequent authorization request, grant, denial, or banner-related log line ever appears. This suggests the notification service object initializes but never actually calls UNUserNotificationCenter.requestAuthorization() — which would explain why the app never registers with Notification Center at all.

How this differs from the existing notification issues

• #50296 (the canonical report; #50480 was closed as a duplicate of it): there, permission-prompt notifications do fire reliably and only task-completion (Stop) notifications fail — i.e. the app is already registered and permission-granted in System Settings, and the bug is a downstream wiring issue on one event type. This report is a layer lower: the app never registers at all, so there is nothing to configure, no permission grant/deny ever happens, and the completion-notification path can't even be reached. Same area (macOS desktop notifications), different and earlier failure point.

Environment

• App version: 1.17377.2
• Platform: darwin (arm64), Apple M2 (8 cores)
• OS: macOS Tahoe 26.6 Beta / Darwin Kernel 25.6.0
• uname -a: Darwin <hostname> 25.6.0 Darwin Kernel Version 25.6.0: Fri May 15 01:58:00 PDT 2026; root:xnu-12377.160.49.0.1~42/RELEASE_ARM64_T8112 arm64
• Deployment mode: 1P (no MDM/managed config — managed-config.txt shows Source: none)
• No crash reports (dmp-names.txt empty)

Supporting log evidence

[info] NotificationService initialized with UNUserNotificationCenter (macOS) appears once per launch (3/3 launches in the diagnostic bundle). No line matching authorization, permission, banner, granted, or denied (for notifications specifically) appears anywhere else in the log.

Additional context

• #43654 — Claude Desktop failing to launch on macOS Tahoe 26.x, traced to LaunchServices not registering the app bundle correctly and stale TCC state under the same bundle ID (com.anthropic.claudefordesktop). Notification registration may be failing for a related underlying reason (LaunchServices / TCC registration under that bundle ID), though I haven't confirmed the exact mechanism.
• #68484 — desktop extension installs silently failing on macOS Tahoe 26.5 with no error and no user feedback. Cited only for the broader pattern of silent, feedback-less failures on Tahoe 26.x that this bug shares, not as the same subsystem.
• The key log evidence is quoted above. I can share additional relevant sections of the diagnostic export (redacted) if a maintainer needs them.

What Anthropic could check

• Confirm whether UNUserNotificationCenter.requestAuthorization() is actually being called after NotificationService initializes, and whether that call's completion handler is logged. If it is never called, that alone would explain the missing System Settings entry.
• Confirm whether this reproduces on non-beta macOS (Sequoia) with the same app version, to isolate a Tahoe-beta-specific vs. general regression.

What Should Happen?

After triggering a permission-prompt or response-completion notification while Claude is not frontmost, a "Claude" entry should appear in System Settings → Notifications (per the documented behavior that the desktop app sends an OS notification when a Code session needs input and you aren't viewing it).

Error Messages/Logs

From main-log.txt (three consecutive app launches, timestamps redacted to relative):

[info] NotificationService initialized with UNUserNotificationCenter (macOS)

This line appears once per launch (3/3 launches in the attached diagnostic bundle). No line matching authorization, permission, banner, granted, or denied (for notifications specifically) appears anywhere else in the log.

Steps to Reproduce

1. Fresh install of Claude Desktop, log in, confirm "응답 완료" (Response completions) and "Code 권한 요청" (Code permission request) toggles are on in Settings → Notifications.
2. Start a Code-tab action that requires permission approval.
3. Before the permission prompt appears, Cmd+Tab to a different app (e.g. Finder) so it becomes frontmost (verified via the menu bar app name, not just window minimized).
4. Wait for the permission prompt to fire inside the session.
5. Check System Settings → Notifications for a "Claude" entry.

Also tried:

1. Full uninstall (including ~/Library/Application Support/Claude and ~/Library/Caches/Claude) and reinstall from claude.ai/download, then repeat steps 2–5.
2. tccutil reset All com.anthropic.claudefordesktop in Terminal (returned "Successfully reset All approval status"), relaunch, repeat steps 2–5.
3. Sanity check that the macOS notification pipeline itself works: osascript -e 'display notification "test" with title "Claude"' in Terminal — this successfully shows a banner and registers a "스크립트 편집기" (Script Editor) entry in System Settings, confirming the OS-level notification system is functional and it's specifically Claude.app that never registers.

Actual: No entry for "Claude" ever appears in System Settings → Notifications under any of the attempts above (including after full reinstall and TCC reset). No banner, no error, and no console/UI indication that anything failed.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.198 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_