Claude Code notifications on a Mac, and approving prompts from the notch

If you use Claude Code for real work, you know the pattern. You give it a task, switch to something else, and come back ten minutes later to find it has been sitting on a question for nine of them: can I run this command? The terminal was behind your browser, so nothing told you.

This post covers three ways to fix that on a Mac, from a two-minute setting to answering prompts without touching the terminal at all. The first two are free and built on Claude Code's own features.

Why Claude Code stops

Claude Code asks before it does anything with side effects that you have not already allowed: running a shell command, editing a file, fetching a URL. That is a good default. You can loosen it with allow rules in your settings, but most people keep some prompts, because a coding agent with unlimited permissions on your machine is a risk.

So the prompts stay, and the problem becomes noticing them. There are two moments you care about:

It needs you. A permission prompt, or a question it cannot answer alone.
It is done. The task finished and it is waiting for your next instruction.

Option 1: the built-in notification setting

Claude Code can alert you itself. Run /config inside a session and look for the notification setting. Depending on your terminal and version, you can choose a terminal bell or iTerm2's own notifications. With a bell, most terminals will bounce the Dock icon or show a badge when a background tab rings. Check your terminal's settings for how it handles the bell.

This is the quickest fix and worth doing today. Its limit is that it tells you something happened, not what, and not in which session if you run several.

Option 2: a hook that posts a macOS notification

Claude Code supports hooks: shell commands it runs at set points in a session. They live in your settings file, ~/.claude/settings.json for every project, or .claude/settings.json inside one project. You can also manage them from the /hooks command in a session.

The hook events that matter here are Notification, which runs when Claude Code sends a notification (for example when it needs your permission or has been waiting for input), and Stop, which runs when it finishes responding. macOS can post a native notification from the command line with AppleScript, so a minimal hook looks like this:

{
  "hooks": {
    "Notification": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "osascript -e 'display notification \"Claude Code needs you\" with title \"Claude Code\"'"
          }
        ]
      }
    ]
  }
}

Add the same block under Stop if you also want to hear when a task is done. The first time it runs, macOS may ask whether your terminal (or Script Editor) can send notifications. Allow it in System Settings, under Notifications.

A few tips from living with this setup:

Hooks receive details about the event as JSON on standard input, including the session and the notification's message. A small script can read that and put the project name in the notification's title, which helps a lot with several sessions open.
Keep hooks fast. Claude Code waits for a hook to finish, and a slow one slows every event it is attached to.
Hooks run with your user's permissions. Only add commands you understand, and be careful copying hook configurations from the internet.

The Claude Code documentation on hooks lists every event and the exact input each one receives. It is worth reading once, because the same mechanism can run formatters, block edits to certain files, or log what the agent does.

The limit of notifications

Notifications solve noticing. They do not solve the round trip. When a notification says Claude needs permission, you still have to find the right terminal window, find the right tab, read the prompt and press a key. With three or four sessions in different projects, that is a lot of window switching for what is usually a one-word answer.

Notifications also pile up. macOS shows them for a few seconds, then files them in Notification Centre, where it is easy to lose track of which session is still waiting and which one you already answered.

What you want instead is a live view: every session's state in one place, all the time, with the question right there when one needs you.

Option 3: answer from the notch

Claude Code has a hook event for this too: PermissionRequest. It runs when Claude Code is about to show you a permission prompt, and a hook can answer it by allowing or denying on your behalf. That makes it possible for another app to show the prompt to you somewhere more convenient and pass your answer back.

This is what we built Crowny around. It watches the Claude Code, Codex and Grok sessions you start in Terminal, iTerm, Ghostty or Warp, and gives each one a small face in the MacBook notch that shows whether it is working, thinking, done, or waiting on you. Turn on the Claude Code hook in Crowny's setup and a permission prompt appears in the notch with the command it wants to run. Click to allow or deny, and the session carries on. The terminal never has to come to the front.

Because the notch is always in view, you do not need a notification to notice. A session that needs you looks different from one that is busy, at a glance, from any app. When a session finishes, Crowny shows a short note and goes quiet again.

One honest limit: "anywhere" here means anywhere on your Mac. Crowny does not send prompts to your phone. If you want to approve from another device, you need a different setup.

Which option to pick

One session at a time, now and then: the built-in setting is enough.
You like to tinker: a Notification and Stop hook gives you native alerts in a few lines.
Several sessions, all day: a live view with answers in place saves the most time. That is the case Crowny is for.

If the third one sounds like you, you can download Crowny and see what a licence includes. Pay once, no subscription. And if you are on a Claude plan, read our guide on tracking your usage limits next, since the other thing that stops a session is running out.