Get a Ding the Moment Codex Needs Your Response

There are two moments when a coding agent should make noise. When it's done — and, far more urgently, when it has stopped to ask you something. A Codex CLI session sitting at an approval prompt isn't working; it's waiting. Every silent minute there is a minute of compute and momentum lost because a yes/no question printed to a terminal you weren't looking at.

The good news: you don't need scripts, tmux tricks, or terminal bell hacks for this anymore. Codex has a built-in setting that fires a desktop notification at exactly that moment — it's just not the setting most guides talk about. Here's how to get a reliable ding when Codex needs your response, plus the matching setup for Claude Code and Cursor.

Why your notify hook stays silent at approval prompts

Most Codex notification setups use the notify hook in ~/.codex/config.toml — an external program Codex runs when an event happens. It's a great tool, and we cover it in depth in our Codex CLI notifications guide. But it has a blind spot that surprises almost everyone: the external notify hook fires on agent-turn-complete — when Codex finishes a turn — and not when Codex pauses mid-task to request approval.

So you set up a lovely chime, confirm it rings when a task ends, and then still come back to a session that spent twenty minutes stuck on "allow this command?" with no sound at all. The done-ding works; the needs-you ding never fires.

The built-in fix: tui.notifications

Codex's terminal UI has its own notification channel, separate from the external hook, and it understands two event types: agent-turn-complete and approval-requested. Turn it on in ~/.codex/config.toml:

# ~/.codex/config.toml
[tui]
notifications = true

With notifications = true you get desktop notifications for both events. If you only want the ding when Codex is blocked on you — and silence when it simply finishes — filter it down to the one event that matters:

# ~/.codex/config.toml
[tui]
notifications = ["approval-requested"]

That single line is the answer to the "ding when prompt response needed" problem: Codex pauses for approval, your desktop pings, you tab over, hit yes, and the agent keeps moving. The inverse filter (["agent-turn-complete"]) exists too, if approval noise ever gets excessive on a permissive config.

The catch: your terminal has to cooperate

Unlike the external hook — which runs any program you point it at — TUI notifications are delivered through terminal escape codes. Your terminal emulator has to translate them into system notifications, and support varies:

• Works well: iTerm2, WezTerm, Kitty and Ghostty all understand the relevant escape sequences. In iTerm2, also allow notifications in Settings → Profiles → Terminal.
• Doesn't work: macOS Terminal.app ignores these sequences entirely — no amount of config.toml editing will make it ding.
• Extra rule: most terminals only surface the notification when the window is unfocused — which is what you want, since that's precisely when you're not watching.

If you're on a terminal that doesn't play along, you have two options: switch terminals, or skip the plumbing entirely with a native notifier app — more on that below.

The same setup for Claude Code

Claude Code solved this from the other direction: its hook system has a dedicated Notification event that fires when Claude needs permission to use a tool or has been idle waiting for your input. A minimal ~/.claude/settings.json entry:

{
  "hooks": {
    "Notification": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "afplay /System/Library/Sounds/Funk.aiff"
          }
        ]
      }
    ]
  }
}

That plays a distinct sound whenever Claude Code is waiting on you — use a different sound for the Stop hook and you'll know without looking whether it's done or blocked. Full recipes, including banners and phone pings, are in our copy-paste notification scripts post.

Cursor's agent sits somewhere in between: it can notify when a run finishes, but the waiting-for-confirmation case is exactly where its built-in options are thinnest — our Cursor notification guide walks through what's possible there.

One agent is config. Three agents is a chore.

Notice what just happened: three tools, three completely different mechanisms — a TOML table read by a TUI, a JSON hooks file, and an IDE's notification settings. Each breaks differently, each lives on one machine, and none of them share a definition of "needs input." The config is easy once; maintaining it across every agent, terminal and laptop you touch is the part that quietly stops happening.

However you wire it up — tui.notifications, a Claude Code hook, or a native app that watches everything — the principle is the same: the expensive resource in an agentic workflow isn't the model, it's your attention. A ding at the moment an agent needs a response is the cheapest productivity upgrade available this year. Set it up once and stop paying the waiting tax.