›_ Codex Issues
Codex Issues / #17716

Emit "approval-requested" desktop notification for request_permissions prompt

Open 💬 8 comments Opened Apr 13, 2026 by Mygod
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.120.0

What subscription do you have?

Pro

Which model were you using?

gpt-5.4

What platform is your computer?

Linux 6.8.0-107-generic x86_64 x86_64

What terminal emulator and version are you using (if applicable)?

ghostty

What issue are you seeing?

When a turn reaches the built-in request_permissions tool in Codex CLI TUI, Codex shows the permission approval prompt and waits for input, but no desktop notification appears for that prompt.

This makes it easy to miss the request when the terminal is unfocused, leaving the session blocked waiting for approval.

The prompt itself appears normally in the TUI, for example:

Would you like to grant these permissions?

Reason: <reason>

1. Yes, grant these permissions (y)
2. Yes, grant these permissions for this session (a)
3. No, continue without permissions (n)

The issue is not that the prompt fails to render. The issue is that no corresponding desktop notification / approval-requested notification seems to fire for this request_permissions path.

What steps can reproduce the bug?

  1. Start Codex CLI TUI with desktop notifications enabled for approval events, for example:
[tui]
notifications = ["approval-requested"]
  1. Start a turn that can reach the built-in request_permissions tool.
  2. Make the terminal unfocused before the permission request is emitted.
  3. Let the turn reach a request_permissions prompt.
  4. Observe that Codex is waiting on the permission prompt when you return to the terminal.
  5. Observe that no desktop notification was emitted for that prompt.

I do not have a thread id to attach for this repro.

What is the expected behavior?

A request_permissions prompt should trigger the same kind of approval notification as other blocking approval flows, so the user is notified when Codex is waiting for permission while the terminal is unfocused.

At minimum, this path should emit a desktop notification consistent with approval-requested.

Additional information

Current code also suggests this is a bug rather than a feature request. In codex-rs/tui/src/chatwidget.rs on current main:

  • handle_request_user_input_now(...) calls self.notify(...)
  • handle_request_permissions_now(...) does not call self.notify(...)
  • existing approval notifications already exist for exec/edit/elicitation paths

So this looks like request_permissions is missing from an existing notification path rather than lacking a brand-new feature.

View original on GitHub ↗

8 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #17252

Powered by Codex Action

etraut-openai contributor · 3 months ago

This feature requires a terminal that supports osc9 escape sequences, and your terminal needs to be configured to show notifications.

Try switching to bel notifications (a simple beep) to see if that works for you. You can do this by adding notification_method = "bel" under the [tui] section.

Mygod · 3 months ago

I think this may be a different issue.

I agree terminal notification backend support matters for whether a posted notification is visible/audible. But in current main, the request_permissions path appears not to post a notification at all.

Relevant code:

  • handle_request_user_input_now(...) calls self.notify(...):

https://github.com/openai/codex/blob/280a4a6d42c150fe5fa5133e7f265fe59aeec781/codex-rs/tui/src/chatwidget.rs#L4557-L4566

  • handle_request_permissions_now(...) does not call self.notify(...):

https://github.com/openai/codex/blob/280a4a6d42c150fe5fa5133e7f265fe59aeec781/codex-rs/tui/src/chatwidget.rs#L4571-L4582

  • The notification enum/type mapping on main does not include a request_permissions notification path:

https://github.com/openai/codex/blob/280a4a6d42c150fe5fa5133e7f265fe59aeec781/codex-rs/tui/src/chatwidget.rs#L10675-L10723

So BEL vs OSC 9 affects delivery, but this specific path appears to be missing the emit step.

I can also repro this as a differential test:

  • exec approval prompt => notification fires
  • request_permissions prompt => no notification fires

If helpful, I can open a PR or provide a smaller repro.

Mygod · 3 months ago

I implemented a local fix for this in my fork and verified that it fixes the issue locally: https://github.com/Mygod/codex/commit/537413eb2b0f1d26987caca841efb7ce193f6e57

The problem appears to be the missing notification emit in the request_permissions path. My patch emits a TUI notification from handle_request_permissions_now(...), routes it through the existing approval-requested category, and adds regression tests. cargo test -p codex-tui passes locally.

etraut-openai contributor · 3 months ago

Changing this from a bug report to an enhancement request.

constansino · 2 months ago

I published a small hook-based workaround that may help with this class of "Codex is blocked waiting for me" problems on macOS:

https://github.com/constansino/codex-attention-notifier

It uses Codex hooks to send a native macOS notification for PermissionRequest events.

It is not a first-party fix for the missing notification path described in this issue, and it cannot detect every child process that blocks on stdin after it has already started. It is a practical workaround for approval cases while the native notification behavior is still being improved.

More details:

https://github.com/openai/codex/discussions/21354

hendryyeh · 2 months ago

I ran into the same class of problem while building CodeVibe, which lets people monitor and respond to local coding-agent sessions from mobile.

One thing we learned the hard way: a generic tool lifecycle signal is not enough for this UX. We initially treated early tool events like “probably waiting for approval,” but that creates false positives because some tools are auto-approved or policy-approved. For a remote/mobile approval surface, the useful signal is specifically:

  • Codex is blocked waiting for user input
  • the exact prompt/options shown in the TUI
  • the command/tool context
  • a stable prompt id
  • the eventual approval/deny outcome

For now we work around this in CodeVibe by using Codex’s PermissionRequest hook when trusted, then verifying the exact desktop prompt/options from tmux before sending a mobile approval prompt. If the exact options are unavailable, we suppress rather than guess, because sending the wrong approval key would be worse than no notification.

So +1 to this request. Adding request_permissions to the same approval-requested notification path would help desktop users immediately, and a stable machine-readable approval event would make external UIs much safer than scraping terminal state.

For reference, this is the product/workaround we built around this gap: https://quantiya.ai/codevibe

AminDhouib · 2 months ago

This still sounds like it needs a Codex-side fix if the request_permissions path is not emitting a notification event at all.

For people who want a broader workaround around “Codex is waiting and I’m away from the terminal,” we built ai-agent-notifier to route Codex task-complete and needs-input style events into desktop toasts and optional ntfy phone push: https://github.com/DevinoSolutions/ai-agent-notifier

Just run npx ai-agent-notifier setup, reset your current sessions, and you are good to go!

---

https://github.com/user-attachments/assets/5714b528-7e04-478e-abfd-2a3d05db562c

Watch on YouTube