hooks: add permission request event for parity with claude code's auto-approve flow

Resolved 💬 6 comments Opened Mar 31, 2026 by yigitkonur Closed Apr 22, 2026

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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.

thanks for considering!

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 3 months ago

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

#15311
#14754

Powered by Codex Action

yigitkonur · 3 months ago

just noticed #15311 which asks for a similar blocking permission hook. wanted to clarify why this isn't a duplicate:

#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.

dpritchett · 3 months ago

+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.

abhinav-oai contributor · 2 months ago

Added in https://github.com/openai/codex/pull/17563

https://developers.openai.com/codex/hooks#permissionrequest

sanyathoque · 2 months ago

+1 from an external-integration perspective.

A PermissionRequest hook becomes much more useful if payloads include stable correlation metadata:

session_id
run_id (or equivalent execution id)
permission_type (plan exit, dangerous command, etc.)
optional request_id for idempotent allow/deny responses

That would allow policy engines to make deterministic decisions and produce auditable approval trails, while preserving current interactive behavior.

oxysoft · 2 months ago

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.