Cursor Alerts Explained: Every Alert Cursor Raises, and How to Control Them

"Cursor alert" is one of those searches that covers four different problems wearing the same coat. Some people mean the sound that plays when the agent finishes. Some mean the banner that is supposed to appear when the agent stops to ask a question and doesn't. Some mean the approval prompt for a terminal command. And a decent number mean the opposite thing entirely — Cursor is alerting them constantly and they want it to stop.

They are genuinely different mechanisms with different settings and different failure modes, which is why advice that fixes one does nothing for another. Here is the taxonomy, what controls each one, and which of them are known to be unreliable.

The four alerts Cursor can raise

• Completion alerts. The agent finished its turn. This is a sound, and optionally a system notification.
• Attention alerts. The agent has stopped mid-task and is waiting on you — a clarifying question, a choice between approaches, or a plan to confirm.
• Approval prompts. The agent wants to run a terminal command or touch something outside its allowlist. This is not really a notification — it is a blocking gate rendered inside the chat pane.
• Editor diagnostics. Squiggles, problem-panel entries, lint and type errors. Nothing to do with the agent, and the thing a surprising share of "cursor alert" searches actually mean.

The distinction that matters most in practice is the first versus the second. A completion alert tells you the work is over. An attention alert tells you the work has stalled. Missing the second one is far more expensive: a finished task sits there harmlessly, while a stalled task burns wall-clock time doing nothing at all.

Turning on the ones you want

Both notification types live in Cursor's settings, and system notifications in particular are off by default — open settings and look under Notifications for the system notifications toggle. There is a separate completion sound toggle under the chat settings. Searching the settings pane for "notification" surfaces whatever your build exposes, which varies a little by version.

Thirty seconds of settings work covers the case where you are sitting at the machine. It stops covering you the moment any of the following is true:

• You run several Cursor windows. A single anonymous ding cannot tell you which project needs you.
• You have Do Not Disturb or a macOS Focus mode on while you work. Banners get suppressed exactly when you are concentrating hard enough to need them.
• You leave the room. Neither a sound nor a banner reaches the kitchen.

The attention alert is the flaky one

This is worth saying plainly because people assume they have misconfigured something. Cursor users have repeatedly reported that notifications for an agent needing input fire unreliably — particularly when several agents run in parallel, where the menu-bar alert that used to appear now shows up rarely or not at all. There are open community reports about exactly this on macOS.

So if your experience is "the done sound works but I never get told when it is stuck", that is not you. It is the least dependable alert in the product and the one you can least afford to miss. Treat it as something to cover with your own plumbing rather than something to keep re-toggling.

Building an alert that actually fires

Cursor supports hooks defined in a hooks.json at the project or user level. The stop event fires on agent completion and spawns your script with JSON context on stdin, so you can raise a desktop notification, play a distinct sound per project, or curl a push service.

This is the reliable path for completion. It is also the point at which you have signed up to maintain a small pile of shell scripts across every machine and repo you work in, and to redo it for every other agent you use. That cost is real and it is why most people who start down this road abandon it after the second project.

Making Cursor alert you less

The inverse problem deserves its own answer, because the usual advice makes it worse. If Cursor is interrupting constantly, the volume is almost always approval prompts rather than notifications — and the fix is not to disable alerts, it is to widen what the agent is allowed to do without asking. An allowlist for the commands you already always approve removes dozens of interruptions a day without removing the ones that matter.

Turning off notifications to reduce noise is the wrong lever. It silences the completion and attention alerts — the two signals with actual information — and leaves every blocking prompt exactly where it was.

The zero-config option

This is the gap AI Done Now exists to close. It is a native app that watches your AI coding tools — Cursor, Claude Code, Codex CLI and the rest — and alerts you the moment an agent finishes or is waiting on your input, with desktop and phone notifications and per-source labelling so you know which window wants you. No hooks to write, no scripts to keep in sync across machines. The specifics are on the Cursor agent notifications page.

Which alert setup fits you

• One window, always at the desk: the built-in sound plus system notifications is genuinely enough.
• Several projects in parallel: you need per-source alerts. This is where a single undifferentiated ding stops being useful and where the built-in attention alert is least reliable.
• You step away while agents run: phone push is the only thing that works — your own ntfy plumbing or an app that ships it.
• You are drowning in prompts: fix the allowlist, not the notifications.

The theme is the one that runs through most of this blog (see every way to get notified when Cursor finishes and the case against watching the terminal): an agent is only a productivity win if you can stop watching it. An alert you cannot trust is worse than no alert, because it keeps you half-watching — which is the one state that costs you both the waiting time and the attention.