macOS Delivers No Notifications — Stuck Game Mode From a Zombie App¶

TL;DR — If macOS stops delivering all notifications and Focus/Do-Not-Disturb is not on, check whether Game Mode is stuck on. Game Mode suppresses notifications by design, and a wedged/zombie app (often an iOS-app-on-Mac) can hold the StandardGameMode assertion indefinitely via gamepolicyd. Kill the zombie to release it; reboot to fully restore delivery (the notification daemon usernoted is SIP-protected and can't be restarted from the CLI).

Symptom¶

No notifications at all — no banners from any app.
Focus / Do Not Disturb is off (no Focus pill in Notification Center, per-app notifications enabled in System Settings).
Possibly a stray "spaceship" (Game Mode) icon in the menu bar that does nothing; toggling Game Mode in Control Center may add a second icon while a dead first one lingers.

Why this happens¶

macOS Game Mode deprioritizes background work and suppresses notifications while a game is in the foreground. The policy daemon gamepolicyd holds a StandardGameMode assertion for the running game and is supposed to release it when the game exits.

If a game-classified app becomes a zombie — still listed as running by LaunchServices but with no window-server connection (e.g. an iOS-app-on-Mac that got wedged days ago) — gamepolicyd keeps Game Mode pinned for it. Notifications stay suppressed indefinitely, even though you're not actively playing anything.

Diagnosis¶

Confirm Game Mode is stuck on, and find what's holding it, in the logs:

# Is StandardGameMode being acquired and never released?
log show --last 6h --predicate 'eventMessage CONTAINS "StandardGameMode"' --style compact

# Services denied "due to current system state [StandardGameMode]" = Game Mode is active
log show --last 1h --predicate 'eventMessage CONTAINS "current system state"' --style compact

Find the zombie holder — a long-elapsed, 0% CPU, game-classified process (often an iOS app under a Wrapper/ path):

ps -axo pid,etime,%cpu,state,comm | grep -i -E "wrapper|<suspect-app>"

A multi-day ELAPSED with S/0% CPU and no UI is the giveaway.

Fix¶

Kill the zombie holding the assertion:
```
kill <pid>
```
Confirm no new StandardGameMode "Acquiring" events and no further policy denials in the log — Game Mode is now released.
Reboot to fully restore delivery. The kill releases Game Mode, but the notification daemon usernoted is SIP-protected and can't be restarted from the CLI (launchctl kickstart -k → "Operation not permitted while System Integrity Protection is engaged"). A reboot restarts it fresh and clears any residual suppression. After reboot, test with a real app (send yourself an iMessage, wait for a Mail/Slack banner) — confirmed delivery means resolved.

Red herrings — don't chase these¶

com.apple.ncprefs "domain does not exist", missing notification db2, empty ~/Library/DoNotDisturb — these are DataVault/TCC access artifacts on recent macOS; the CLI simply can't read the protected store. They do not mean the notification database is corrupt or wiped.
osascript display notification tests are unreliable — a CLI notification is attributed to a host app that may itself be muted, so "I didn't see it" proves nothing. Always test with a real app.
usernoted "won't restart" — expected; it's SIP-protected. That's why a reboot is required rather than a daemon kick.
Focus / Do Not Disturb — rule it out early, but if it's genuinely off, it's not your culprit.

Key takeaways - All notifications silent + Focus off ⇒ suspect Game Mode stuck on. - A zombie game-classified app (frequently an iOS-app-on-Mac) can pin Game Mode for days; kill it to release. - The notification daemon is SIP-protected, so reboot to fully restore — and test with a real app, not osascript.