macOS Desktop App: permission requests trigger OS notifications but task completion does not

Summary

Claude Desktop app on macOS: permission-prompt events fire a native OS notification reliably. Task completion (Stop event) never does — even with the in-app Response notifications toggle enabled.

Environment: Claude Desktop 1.3109.0, macOS 15.7.5 (24G624).

Repro

1. Notifications allowed for Claude.app in System Settings → Notifications.
2. Claude Desktop → Settings → Notifications → Response notifications = on.
3. Prompt that triggers a permission prompt, window unfocused → banner ✅
4. Prompt that runs to completion (no permission needed), window unfocused → no banner ❌

Same window state, same app, same user. Only the event type differs.

Ruled out before filing

• macOS permission. Banners fire fine for permission prompts — the OS-level permission path works.
• Window-visibility suppression. Same reason; permission prompts punch through in the exact same window state.
• Local hook interference. Disabled, one at a time with a full quit+reopen of Claude.app between each:
• Stop / Notification hooks in ~/.claude/settings.json
• Codex CLI notify in ~/.codex/config.toml
• Ghostty notify-on-command-finish
• zsh command-finish hook
• ralph-loop plugin Stop hook

Symptom persists unchanged with everything disabled.

• Workaround attempt. Wired a Notification hook matching idle_prompt to terminal-notifier -sender com.anthropic.claudefordesktop. The hook fires — confirmed via logfile written from the helper script — but the banner never lands in Notification Center (confirmed via terminal-notifier -list ALL, where Claude-sender entries are absent while unsigned control entries are present). Unsigned fallbacks (osascript, plain terminal-notifier) do deliver, but branded as "Script Editor" / "terminal-notifier," which isn't usable.

Possibly-relevant clue

The help text under the in-app Response notifications toggle references "Claude Code on the web" — not local desktop Code sessions. May suggest the desktop completion path isn't wired to that toggle at all, which would explain why flipping it has no observable effect.

Related (distinct)

• #9878 — broader ask, not desktop-specific
• #20525 — scoped to run_in_background tasks
• #42336 — PostToolUse hooks not firing in desktop app (may share root cause with the workaround attempt above)