Skip to content

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

Closed

Description

@yigitkonur

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!

Activity

  1. added
    enhancementNew feature or request
    CLIIssues related to the Codex CLI
    sandboxIssues related to permissions or sandboxing
    on Mar 31, 2026
  2. github-actions commented on Mar 31, 2026

    @github-actions
    Contributor
  3. yigitkonur commented on Mar 31, 2026

    @yigitkonur
    Author

    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.

  4. added
    agentIssues related to the core agent loop
    hooksIssues related to event hooks
    and removed
    sandboxIssues related to permissions or sandboxing
    CLIIssues related to the Codex CLI
    on Mar 31, 2026
  5. dpritchett commented on Apr 7, 2026

    @dpritchett

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

  6. abhinav-oai commented on Apr 22, 2026

    @abhinav-oai
    Contributor
  7. sanyathoque commented on May 4, 2026

    @sanyathoque

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

  8. oxysoft commented on May 8, 2026

    @oxysoft

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    agentIssues related to the core agent loopenhancementNew feature or requesthooksIssues related to event hooks

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions