DEV Community: Marco Belini

Four ways to hear from Codex on your Apple Watch (only one can answer)

Marco Belini — Thu, 12 Nov 2026 16:28:27 +0000

I make Tapproval, one of the options below, so read this with that in mind. Facts as of 9 November 2026.

Codex stops when it needs you: a command to allow, a file change to approve. If you have stepped away from the keyboard, the work waits until you come back.

There are four ways to have your Apple Watch tell you. They differ in one thing that matters more than it sounds: whether the watch can only tell you, or can also answer.

1. Codex's own alerts, on the computer

The Codex CLI can raise a terminal notification when it needs approval or finishes a turn. In ~/.codex/config.toml, the [tui] table's notifications setting turns them on and can limit them to events such as approval-requested and agent-turn-complete.

They appear on the computer, through your terminal. They reach your wrist only if you are close enough to see the screen.

Good fit if you stay in the room and only need a nudge. Nothing to install.

2. A notify script that pings your phone

Codex can also run a program of your choice, set with notify in the same file. It hands the program one JSON argument describing the turn. A short script there can send a push through ntfy or Pushover, and your watch shows it like any other phone notification.

The limit: Codex's configuration guide says notify currently fires only for agent-turn-complete. It tells you a turn is done, not that Codex is waiting for permission. For approvals, a script has to sit in a Codex hook instead.

3. The ChatGPT app on your iPhone

OpenAI's remote connections let the ChatGPT app on a phone follow Codex on a computer, approve commands and get notified when a task completes or needs you. The computer runs the ChatGPT desktop app on macOS or Windows, signed in to the same account as the phone.

Your watch shows the phone's notification the way it shows any iPhone app's. The approval itself is made on the phone.

Good fit if you use Codex through the ChatGPT desktop app and carry your phone.

4. A watch app that answers

The fourth kind puts the question itself on the watch and sends your answer back. On the computer, a hook in Codex's hooks.json hands each permission question to a small relay; the watch app shows it, and one tap answers.

Tapproval works this way. Each question arrives marked with one of five risk tiers, worked out on your own computer, so a force-push to main shows as CRITICAL before you tap. You can also follow a Codex chat live and reply to it from the wrist. The helper on the computer is open source and uses only Python's standard library; there is no account and no server of mine in between. The first 100 answers are free, then $5 once. No subscription.

Others exist: Agent Approve has a watch app and lists Codex among its agents, on a monthly subscription. My comparison page sets them side by side, with the source for every claim.

One thing none of these change: Codex's own approval settings still decide which actions ask at all. Tapproval approves nothing on its own; every card that reaches the watch waits for your tap.

When your iPhone is not with you

This is where the four part ways. Apple sends an iPhone app's notifications to the watch only while the two are connected. Leave the phone at home and options 2 and 3 go quiet on the wrist; option 1 never left the computer.

A watch app can reach your computer on its own over the internet, on Wi-Fi or cellular. That is the case I built for: walking the dog while an agent works.

Side by side

	Codex alerts	Notify script	ChatGPT app	Watch app
Tells you it needs approval	Yes, on the computer	No, turn finished only	Yes, on the phone	Yes, on the watch
Answer on the watch	No	No	No, on the phone	Yes, one tap
Works with the iPhone away	On the computer only	No	No	Yes
Needs	Nothing	A script and a push service	ChatGPT desktop app, same account	The app and its helper

Setting up the fourth one

Five minutes, three steps:

Get Tapproval from the App Store: search for "Tapproval" on your watch or iPhone (it is a watch app; no iPhone app is needed).
Install the helper on the computer. The one-line command is in the Codex setup guide.
Open codex once and trust the new hook. Codex runs a hook only after you approve it, and the helper never approves it for you.

Then open the app on the watch while both are on the same Wi-Fi. It finds the computer by itself.

If you use Claude Code too, the same install covers both.

Tapproval is an independent app, not affiliated with or endorsed by OpenAI, Anthropic or Apple.

Your Claude Code hook can say "allow" and be ignored, without a single error

Marco Belini — Tue, 13 Oct 2026 13:12:27 +0000

You wrote a PermissionRequest hook. It decides, it prints "allow", your log says "allowed", and Claude Code shows the ordinary prompt anyway. No error, no warning. It looks exactly like a hook that chose to leave the question to you.

We shipped that bug. Every approval tapped on a remote device was thrown away, on every install, for weeks. Here is the one-line cause, and two habits that would have caught it.

The cause: a string where Claude Code wants an object

Older examples print the decision as a string:

"decision": "allow"

Claude Code validates a hook's output. A string fails validation, and a hook that fails validation is treated as non-blocking: the permission flow carries on as if your hook had never answered. The CLI's own validator says what it wants:

PermissionRequest decision must be {"behavior": "allow"} or {"behavior": "deny", "message": "..."}

When we checked, the published hook docs still showed the string form. Trust the validator.

What to print instead

Standard output carries the answer and nothing else. Logs go to standard error.

Allow:

{"hookSpecificOutput": {"hookEventName": "PermissionRequest",
  "decision": {"behavior": "allow"}}}

Deny, with a reason Claude reads and acts on:

{"hookSpecificOutput": {"hookEventName": "PermissionRequest",
  "decision": {"behavior": "deny", "message": "Not on main. Push to a branch."}}}

Leave it to the person by sending no decision at all:

{"hookSpecificOutput": {"hookEventName": "PermissionRequest"}}

Two habits that would have caught it

One function builds the output, and a test checks the exact bytes it prints. Assert that decision is an object with behavior, and that a deny carries a message. Test what you print, not what you meant to print.
Prove one real allow, end to end. Create a marker file, ask a session to delete it, approve the delete through your hook, and check that the file is gone. If it is still there and the ordinary prompt appeared, your answer was ignored.

Wiring, briefly

In ~/.claude/settings.json, or in a plugin's hooks/hooks.json:

{"hooks": {"PermissionRequest": [{"hooks": [
  {"type": "command", "command": "python3 /path/to/your-hook.py", "timeout": 86460}]}]}}

The timeout is in seconds. A hook that waits for a person needs a long one, or the question disappears while they are still reading it. The event arrives as JSON on standard input, with tool_name, tool_input, cwd, and permission_suggestions when the prompt would offer "don't ask again".

Three more traps

Fail closed. If the hook can't parse the event, or crashes partway, print the "leave it to the person" block. Never allow on a guess.
Headless runs skip the hook. A claude -p run has no prompt to show, so it never reaches a PermissionRequest hook. Use --permission-prompt-tool with an MCP tool there.
A lingering prompt isn't your bug. The Claude app on a phone can keep showing a prompt your hook already answered (claude-code#32493). The command ran; the marker test settles it.

Checked against Claude Code 2.1.280, September 2026.

I build Tapproval, an open-source PermissionRequest hook in standard-library Python, with an Apple Watch app that answers these prompts from the wrist. Its tests check the exact JSON, because we learned this the hard way.