Claude Code Notifications Inside Your Editor's Terminal

Most advice about Claude Code notifications quietly assumes you're in Terminal.app or iTerm. A lot of people aren't. They run Claude Code in the terminal panel at the bottom of VS Code, or Cursor, or a JetBrains IDE, because that's where the code already is.

That panel looks like a terminal and behaves like one for almost everything — except notifications, where it is a meaningfully different environment. If you've set up alerts by following a guide and heard nothing, this is usually why.

The editor terminal is not a terminal application

The distinction that matters: your editor is one application that happens to contain a terminal emulator. It is not the terminal emulator. Everything downstream of that — which app the operating system thinks is making noise, which app was granted notification permission, which settings govern the bell — belongs to the editor, not to the shell running inside it.

So when a guide says "allow notifications for your terminal," and you dutifully find Terminal in System Settings and switch it on, you have just granted permission to an application that is not involved.

Why the bell is silent in VS Code and Cursor

Claude Code's simplest signal is the terminal bell. In VS Code it very often does nothing, and the reason is a settings change that caught a lot of people out.

There are two settings, and the obvious one is the wrong one. terminal.integrated.enableBell is the older setting, and it now controls only the visual bell — a flash, not a sound. Audio moved to accessibility.signals.terminalBell, whose default is auto.

And auto does not mean "when it seems useful." It means the sound plays only when a screen reader is detected, or when accessibility mode is explicitly on. On a normal setup, that evaluates to off. The bell is firing correctly and nothing is playing it.

The fix is one line in settings.json:

"accessibility.signals.terminalBell": {
  "sound": "on"
}

Cursor is a VS Code fork, so it inherits this setting and this default. If Cursor has been silent, check the same two keys before assuming anything about Claude Code itself.

macOS permission belongs to the editor

The second layer is the operating system. If your setup uses osascript or a helper to post a real notification rather than ringing the bell, macOS attributes that notification to the application that spawned the process — which, from an editor terminal, is the editor.

So the entry to check in System Settings → Notifications is Code, or Cursor, or your JetBrains IDE. Not Terminal, not iTerm. And it is worth checking rather than assuming: a fresh install prompts once, and if that prompt appeared while you were mid-thought and you dismissed it, the answer was recorded as no.

The same applies to Focus modes. Allowing Terminal through a Focus while your alerts are actually coming from Cursor produces silence that looks exactly like a broken configuration.

JetBrains behaves differently again

JetBrains IDEs have their own notification system layered on top of the OS one, with per-type settings under Appearance & Behavior. The IDE can be permitted at the OS level and still route a given notification to a balloon in the corner that vanishes, or to the event log where nobody looks.

There is also a habit difference worth naming. JetBrains users tend to run the IDE full screen on one display, which means an in-editor notification appears on the screen you have already stopped looking at. That is the failure mode no setting fixes.

The hook approach, which sidesteps the whole problem

Everything above is about persuading a chain of components to pass a signal along. You can skip the chain entirely by having Claude Code fire a notification itself when it finishes, using a hook, rather than relying on the bell reaching a terminal that reaches an editor that reaches the OS.

That is the durable fix, because it does not care which terminal you are in. Our hooks guide covers the setup, and the notification scripts post has ready-made examples.

When not to fight this

One honest caveat. If you keep your editor full screen and your attention inside it, a notification from that same editor is competing with the thing you are already looking at — and it will lose, or it will interrupt something it should not have.

The editor terminal is a great place to run Claude Code and a poor place to be told about it. If a job is long enough that you will genuinely leave the machine, the alert needs to arrive somewhere else: a different app, a different device, a phone. Tuning a bell you will be sitting three feet away from is effort spent on the wrong layer.

A diagnostic order that works

If you are troubleshooting right now, go in this sequence and stop when you find it:

1. Confirm which application actually contains your terminal — this decides everything below.
2. In VS Code or Cursor, set accessibility.signals.terminalBell sound to on.
3. In System Settings → Notifications, find the editor by name and confirm alerts are allowed and not Focus-suppressed.
4. Test with a bare printf bell in that terminal, so you are testing the channel and not Claude Code.
5. If the channel works but you still miss things, the problem is placement rather than plumbing — move the alert off the screen you are staring at.

If none of that lands, the more general diagnostic checklist walks the whole chain from channel to attention.