You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
hooks: add permission request event for parity with claude code's auto-approve flow #16301
hey, love the hooks system — been using it heavily.
one thing that's missing compared to claude code's hook model is a PermissionRequest event (or something equivalent). in claude code, you can hook into permission decisions like plan mode exit and auto-approve them programmatically. this is super useful for power users who want uninterrupted agentic flows.
what claude code has that codex doesn't
claude code fires a PermissionRequest hook with matchers like ExitPlanMode. your hook script receives the event on stdin, and you return a json decision:
{"behavior": "allow"}
you can also inject additional context alongside the approval:
{
"decision": {"behavior": "allow"},
"additionalContext": "execute step by step, use subagents for parallel work"
}
this lets you build things like:
auto-approve plan mode exit without clicking through the dialog every time
inject orchestrator directives that guide execution after approval
conditionally deny certain permission requests based on custom policy
i built a small tool around this for claude code: https://github.com/yigitkonur/hooks-claude-code — it auto-approves plans and optionally injects an orchestrator prompt. would love to build the same thing for codex.
what i'd like to see
a new hook event (maybe PermissionRequest or PlanApproval) that fires whenever codex needs user confirmation for something — plan approval, dangerous command confirmation, etc. the hook should be able to:
return allow/deny decisions
optionally attach context or instructions
use matchers to target specific permission types
the existing PreToolUse deny flow is close but only covers bash commands. this would generalize that pattern to any permission gate in the system.
current workaround
there isn't really one. Stop hook can force continuation but that's not the same as approving a plan before execution starts.
just noticed #15311 which asks for a similar blocking permission hook. wanted to clarify why this isn't a duplicate:
Add blocking PermissionRequest hook for external approval UIs #15311 is focused on external approval UIs — desktop overlays, IDE extensions, CI/CD pipelines that want to intercept and handle tool approval outside the TUI. their main use case is sending approval responses back from an external process.
this issue is about programmatic auto-approval via hooks, specifically for plan mode exit and similar permission gates. the use case is power users who want uninterrupted agentic flows without clicking through dialogs, with optional context injection alongside the approval decision (like injecting orchestrator directives when a plan is approved).
the underlying mechanism could absolutely be the same event type, but the ask is different — #15311 wants a bridge to external UIs, this one wants a lightweight hook that returns allow/deny + additionalContext inline, modeled after how claude code's PermissionRequest + ExitPlanMode matcher works today.
would be great if both use cases land in one design though.
+1, but my main need is observability, not external auto-approve. I want a stable machine-readable event when Codex is blocked waiting on user approval so local tooling can play a sound, tint the terminal, or send a notification. Today I have to infer that state from transcript wording and internal artifacts, which is brittle.
“Blocked until user responds to approval prompt” is the highest-priority attention signal I care about. A basic Stop/“it’s your turn again” signal is lower priority, since there’s a good chance Codex already finished the task successfully.
Reacted by Ivan Oreshnikov, Jordan Munch O'Hare, Eric Bonet and Zachary Mattor
Indexed this hook ticket in the umbrella tracker: #21753
Goal: collect the scattered Codex hook requests and bugs into one parity matrix for Full Claude Code Hook Parity (29+), while preserving this issue as the detailed thread for its specific behavior.
Activity
github-actions commentedon Mar 31, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
yigitkonur commentedon Mar 31, 2026
just noticed #15311 which asks for a similar blocking permission hook. wanted to clarify why this isn't a duplicate:
Add blocking PermissionRequest hook for external approval UIs #15311 is focused on external approval UIs — desktop overlays, IDE extensions, CI/CD pipelines that want to intercept and handle tool approval outside the TUI. their main use case is sending approval responses back from an external process.
this issue is about programmatic auto-approval via hooks, specifically for plan mode exit and similar permission gates. the use case is power users who want uninterrupted agentic flows without clicking through dialogs, with optional context injection alongside the approval decision (like injecting orchestrator directives when a plan is approved).
the underlying mechanism could absolutely be the same event type, but the ask is different — #15311 wants a bridge to external UIs, this one wants a lightweight hook that returns allow/deny + additionalContext inline, modeled after how claude code's
PermissionRequest+ExitPlanModematcher works today.would be great if both use cases land in one design though.
dpritchett commentedon Apr 7, 2026
+1, but my main need is observability, not external auto-approve. I want a stable machine-readable event when Codex is blocked waiting on user approval so local tooling can play a sound, tint the terminal, or send a notification. Today I have to infer that state from transcript wording and internal artifacts, which is brittle.
“Blocked until user responds to approval prompt” is the highest-priority attention signal I care about. A basic
Stop/“it’s your turn again” signal is lower priority, since there’s a good chance Codex already finished the task successfully.Add PermissionRequest hooks support (#17563)
abhinav-oai commentedon Apr 22, 2026
Added in #17563
https://developers.openai.com/codex/hooks#permissionrequest
sanyathoque commentedon May 4, 2026
+1 from an external-integration perspective.
A
PermissionRequesthook becomes much more useful if payloads include stable correlation metadata:session_idrun_id(or equivalent execution id)permission_type(plan exit, dangerous command, etc.)request_idfor idempotent allow/deny responsesThat would allow policy engines to make deterministic decisions and produce auditable approval trails, while preserving current interactive behavior.
Add PermissionRequest hooks support (openai#17563)
oxysoft commentedon May 8, 2026
Indexed this hook ticket in the umbrella tracker: #21753
Goal: collect the scattered Codex hook requests and bugs into one parity matrix for Full Claude Code Hook Parity (29+), while preserving this issue as the detailed thread for its specific behavior.
Add PermissionRequest hooks support (#17563)
Add PermissionRequest hooks support (openai#17563)
Add PermissionRequest hooks support (#17563)