Codex vs Claude Code Notifications: How Each One Tells You It Is Done

If you run both agents — and a lot of people now do, one in each terminal tab — you will have noticed that getting a Codex notification when it is done and getting a notification when Claude Code finishes are not the same job. They look similar from the outside. Underneath they are built on genuinely different models, and the differences decide which alerts you can get and which ones you simply cannot.

This is a side-by-side of how each one actually signals you, what each can and cannot tell you, and which setup makes sense if you are running both.

The one-paragraph version

Codex CLI gives you one external hook that fires on a single event, plus a separate in-app notification channel that understands two events. Claude Code gives you several hooks on several lifecycle events, plus a built-in channel setting. So Codex is simpler to wire up and harder to extend; Claude Code is more granular and more fiddly. If you want one sentence: Codex tells you when the turn ended, Claude Code can tell you why it ended.

How Codex CLI notifies you

Codex has two independent mechanisms, and conflating them is the most common source of confusion.

1. The external notify hook

In ~/.codex/config.toml you set a top-level notify key to a program. Codex runs that program and hands it a JSON payload describing what happened, including the last assistant message. You do whatever you like with it — play a sound, post to a webhook, raise a banner.

The important constraint: the external hook fires on agent-turn-complete, and that is the event you get. There is no separate external event for an approval prompt, a tool call, or an error. If your script needs to distinguish "finished the work" from "stopped to ask permission", the external hook alone will not give you that distinction.

2. The TUI notifications setting

Separately, Codex's terminal UI has its own notification channel, configured under tui.notifications. This one understands two event types: agent-turn-complete and approval-requested. So if the alert you actually want is "Codex is blocked waiting on me", that is the setting to reach for, not notify.

The practical combination most people land on is both at once: a rich notify script for turn completion, and tui.notifications scoped to approval requests. We walk through the exact config in the Codex CLI notifications guide, and the approval-specific case in getting a ding when Codex needs a response.

How Claude Code notifies you

Claude Code's model is a general hooks system rather than a single notify key. Several lifecycle events can each run a command, and the two that matter for alerts are:

• Stop — fires when Claude finishes responding, once per turn. It receives the final assistant message, which makes it the right place for a "here is what landed" alert that includes a summary.
• Notification — fires when Claude Code wants your attention, which covers permission requests and idle prompts. This is the equivalent of Codex's approval-requested, but it is a first-class hook you can point at any script.

On top of the hooks there is preferredNotifChannel, a setting that controls how Claude Code raises attention through the terminal itself — terminal bell, iTerm2-native notifications, and so on. It is a one-liner, and it is the fastest possible setup: claude config set --global preferredNotifChannel terminal_bell. We covered every channel it accepts in the preferredNotifChannel breakdown, and the full hook setup in the Claude Code notifications guide.

The differences that actually bite

Granularity

This is the big one. Claude Code can distinguish finished from blocked at the hook level, so you can make them sound different without parsing anything. With Codex you get that distinction only by using two separate mechanisms — the external hook for one event and the TUI channel for the other — which means two different places to configure and two different notification styles you do not fully control.

What the payload gives you

Both hand you the final assistant message on turn completion, so both can produce a notification that says something more useful than "done". If you want the banner to read "migrated 14 files, 2 tests failing" rather than a generic chime, either tool will support it — you are writing the same kind of script in both cases.

Where the config lives

Codex keeps everything in one TOML file, which is tidy. Claude Code spreads settings across global and project-level settings files, which is more flexible — you can have a project that notifies differently — and more to keep track of.

What neither one solves

Both are process-local. If the agent is running inside tmux, over SSH, or on a remote box, the notification fires where the process lives, not where you are sitting. That is not a bug in either tool, but it catches people out constantly — we wrote up the failure modes in notifications in tmux and over SSH.

If you run both, do not build the same thing twice

The trap when running Codex and Claude Code side by side is writing two notification scripts that drift. Six weeks later one of them is silently broken because a path moved, and you do not find out until you have spent an afternoon staring at a finished terminal.

A better pattern is one script, two callers. Write a single notifier that takes a tool name, a status, and a message as arguments, then point Codex's notify and Claude Code's Stop and Notification hooks at it. You get consistent alerts, one place to fix things, and the freedom to change how notifications look without touching either agent's config.

Which should you set up first?

If you mostly want to stop babysitting a terminal, start with the blocked alert, not the done alert. The expensive silence is almost never after a task completes — it is the twenty minutes an agent sat waiting for a yes while you read Slack. For Codex that means tui.notifications with approval-requested. For Claude Code it means the Notification hook, or preferredNotifChannel if you want it working in the next thirty seconds.

Add the done alert second. It is the one people configure first and the one that saves less time, because when work finishes the agent stops making noise in a way you eventually notice anyway. When it is blocked, nothing happens at all — and nothing is very easy to miss.