PermissionRequest hooks need a user-facing approval signal for passive notifications
What variant of Codex are you using?
Codex CLI and Codex Desktop / app-server approval flows.
Locally observed with:
codex-cli 0.139.0- Codex Desktop
26.611.62324on macOS
What feature would you like to see?
Please expose whether a PermissionRequest hook corresponds to an approval prompt that actually requires user attention, or add a separate post-routing hook/event for user-facing approval prompts.
A concrete version of the request would be one of:
- Add the effective approval reviewer to
PermissionRequestinput, e.g.approvals_reviewer: "user" | "auto_review" | "guardian_subagent". - Add a direct routing field, e.g.
approval_route: "user" | "auto_review", orrequires_user_input: true. - Add a separate post-routing event/hook such as
UserApprovalRequest/ApprovalPromptShownthat fires only when Codex is actually waiting on the user.
Why this matters
I have a PermissionRequest command hook in ~/.codex/hooks.json that invokes a local notification script. The script uses terminal-notifier on macOS to play a sound and show a notification like "Codex needs permission" with the requested tool name.
When approval reviewer is set to auto_review / "Approve for me", the hook still fires before Codex routes the approval through auto-review. The result is a false positive notification for requests that the automated reviewer can handle without human input.
From the user's perspective, the notification says Codex needs permission, but no user action is actually needed.
The current hook payload does not appear to provide a reliable way to suppress these notifications. permission_mode is still default, and there is no approvals_reviewer, approval_route, or requires_user_input field.
Expected behavior
A passive notification integration should be able to notify only when Codex is actually waiting for the user.
This differs from an external approval UI that wants to decide allow/deny. The hook is not trying to intercept or replace the approval decision. It only wants to notify when attention is required.
Current workaround
The current options are imperfect:
- Use
PermissionRequest, which fires too early and includes auto-reviewed requests. - Use TUI
notifications = ["approval-requested"], which is useful but does not provide the same custom command/icon/sound behavior as an external notification script and does not cover every external integration shape. - Build an app-server/protocol watcher for later approval request events, which is more complex and less appropriate for a simple user hook.
Related
This overlaps with #23465, which asks to expose the effective approval reviewer to PermissionRequest hooks or support explicit defer. This issue is the passive notification use case for the same missing routing signal.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗