[FEATURE] Option to disable notifications

+1

This is very _very_ annoying (and I cant turn off CLI notifications because I have other apps that I use, that need to send notifications via terminal).

It's gotten worse today suddenly — I get a notification for just starting a session, and when Claude Code ticks off a todo from its plan, and just randomly when it is still in the middle of thinking, and of course the usual end of response. It's blocking me from doing focused work with no documented way of turning off or controlling what notifications are sent.

+1

I agree with the comments above. It's sending so many notifications that I'm just ignoring it because it's become noise.

We have a fix for the excessive notifications that should be out in the latest release. Will leave the issue open because it's asking for a setting.

@aaron-trout as a workaround you can configure desktop notifications in Ghostty.

@chrislloyd as in the release thats out? what is the setting?

i'm getting tons of notifications still

Edit: there is a /config for notifications it seems not sure if it's global.

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

Running /config and setting notifications to Disabled worked for me on v2.1.14 with iTerm2 on macOS.
I have custom hooks that notify me when I want with an .sh file so this is a good fix for now.

@JereSalo I created plugin for notifications
https://github.com/777genius/claude-notifications-go
I'm glad if it helps someone

Adding another data point here. This is respectfully annoying as shit, especially for power users running Claude Code across many iTerm2 tabs simultaneously.

The specific problem: Notifications fire from tabs that have been completely dormant for minutes (or longer). When you're managing 5-6+ Claude Code sessions across different projects, you get a barrage of macOS notifications from idle tabs that finished their work ages ago. It makes notification center completely useless because it's flooded with stale "Ready for input" alerts.

My setup:

• Claude Code v2.1.34
• macOS 15.6 (Sequoia)
• iTerm2
• Max Pro subscriber, heavy daily user (174 startups and counting)

Hooks config (~/.claude/settings.json):

{
  "hooks": {
    "Notification": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "/Users/.../.claude/notify.sh 'Ready for input'"
          }
        ]
      }
    ]
  }
}

The notify.sh script uses terminal-notifier with iTerm2 session-aware tab selection (so clicking the notification focuses the right tab). That part works great. The problem is there's no way to suppress or debounce these notifications, so every single Notification event fires regardless of whether the tab is active, foregrounded, or has been sitting idle.

I also have several marketplace plugins installed (hookify, ralph-loop, security-guidance, explanatory-output-style) that register their own hooks on PreToolUse, PostToolUse, Stop, SessionStart, and UserPromptSubmit events. The cumulative effect across multiple tabs is a lot of background process activity from dormant sessions.

What would actually fix this:

1. A preferredNotifChannel: none setting that actually works — this was reported as broken in #19636 (OSC notifications still fire even when set to none)
2. Tab/window focus awareness — don't fire Notification events if the terminal tab is already focused/foregrounded
3. A debounce or cooldown option — if a session has been idle for N minutes, don't keep firing notifications
4. Per-hook conditional logic — let hooks check whether the session is active/idle before executing (e.g., expose $CLAUDE_SESSION_IDLE_SECONDS or $CLAUDE_TAB_FOCUSED as env vars)

Any of these would help. Right now the only workaround is to not use Notification hooks at all, which defeats the purpose of having them.

I second what @kenxle said. I use iTerm2 too, but my setup is much simpler - no hooks, no plugins. Still, whenever I open an idle Claude session I get at least 2 notifications - "New Output" and "Idle". Idle ones then further repeat so one ends up flooded with them.

What I would expect is to be notified when:

1. Claude needs my input
2. Claude finished the work

I do not see much value in other notification types.

<img width="200" alt="Image" src="https://github.com/user-attachments/assets/77143f3a-1a23-48ae-ba94-36e2c9765831" />

I find it quite annoying that Claude sends notification even when it's being focused. I am also using a custom notification shell script, and it would gladly help to have something like CLAUDE_TAB_FOCUSED exposed in order to be able to not send notification for the Claude session being currently focused.

Yes control of notifications needs to be much more granular eg. default first.

Permissions to run commands yes/no
Waiting an answer to a question yes/no
Bored waiting for next prompt no/yes