Hook would be a great feature

[Kare-Udon]

Hi, thanks for your hard work!
I think adding hook features, execute commands at certain events, would be quite useful.
Like when codex needs user to respond, or the process is finished, users can play sounds or send notifications.

[SoraTakai]

+1 on this feature. Would be quite useful to play a sound when the model finishes its response, which usually takes quite a long time.

[tommedema]

I agree we need hooks but for sounds you can do something like notify = ["bash", "-lc", "afplay /System/Library/Sounds/Blow.aiff"] in config.toml (adjust if you're not on mac)

[Elehiggle]

I agree we need hooks but for sounds you can do something like notify = ["bash", "-lc", "afplay /System/Library/Sounds/Blow.aiff"] in config.toml (adjust if you're not on mac)

For Windows:

config.toml:
notify = ["powershell", "-NoProfile", "-ExecutionPolicy", "Bypass", "-File", "C:\\Users\\User\\.codex\\notify.ps1"]

notify.ps1:

param([string]$NotificationJson)

try { $n = $NotificationJson | ConvertFrom-Json } catch { exit 0 }
if ($n.type -ne 'agent-turn-complete') { exit 0 }

$wav = Join-Path $env:WINDIR 'Media\Windows Exclamation.wav'

# Spawn a detached PowerShell to play the sound synchronously, but without blocking Codex
$cmd = "(New-Object System.Media.SoundPlayer '$wav').PlaySync()"
Start-Process -WindowStyle Hidden -FilePath "powershell.exe" -ArgumentList @(
  "-NoProfile", "-ExecutionPolicy", "Bypass", "-Command", $cmd
) | Out-Null

Seperate ps1 was necessary for me, because otherwise it would have syntax errors on codex' side. Works on WSL, too - if you have WSL interop path disabled, use absolute path for powershell: /mnt/c/Windows/System32/WindowsPowerShell/v1.0/powershell.exe

[liunice]

+1 on this feature

[ohnotnow]

I'd also really appreciate this. Even just a basic hook for "I'm done" so we could run a command (to play a sound or whatever) would make it a lot nicer to use. Save me switching windows as often just to check 'is it done yet? no. Is it done yet? no. Is it....'.

[etraut-openai]

There is already a notification hook that is triggered when codex completes a task. For details, refer to this documentation.

[jpcaparas]

Yeah, but that doesn't react to exit code 2, does it? In which case, CC would keep chipping away until the error gets resolved (ie if you were running a "biome check" command as a hook)

[brainit-consulting]

it should a suble 'positive' ping sound yes +1

[ZeldOcarina]

Agreed Claude Code has this!

[Allamss]

+1

[ts-mothership]

+1 for this feature.

I already use hooks with Claude Code by playing a sound when Claude is done or needs feedback (MacOS command /usr/bin/say need feedback). This is a must have for Codex as well!

[babon]

+1 This is a must have now, Cursor just came out with their own Hooks support

[jmilldotdev]

please

[vuyelwadr]

for sure

[mdc-git]

+1

[the-kro]

+1

[shallvtalk]

+1

[miklschmidt]

This is already sort of a thing through the "notify" config setting it just needs more events than "agent-turn-complete".

[tommedema]

and you need to be able to interrupt it or ask for follow-up etc.

[kuzma2022]

+1

[Nabstar3]

This is currently in development as per @etraut-openai. See here:
#2109 (comment)

[danias]

Thanks @Nabstar3 that's great news!

[joshturner35654-lang]

Hi

[ahmetkca]

+1

[ppx123-web]

• 1 on this feature

[asprecic]

Experimentally merged into v0.114!!
https://github.com/openai/codex/releases/tag/rust-v0.114.0
#13276

• Get 0.114 version
• Add hooks.json in .codex or wherever the config directory is.
• Run codex -c features.codex_hooks=true
• Hooks get triggered before/after sending a prompt

{                                                                                                                                                                                                                   
    "hooks": {                                                                                                                                                                                                        
      "SessionStart": [                                                                                                                                                                                               
        {                                                                                                                                                                                                             
          "hooks": [
            {
              "type": "command",
              "command": "echo 'session started' >> /tmp/codex.log",
              "statusMessage": "Initializing session...",
              "timeout": 10
            }
          ]
        }
      ],
      "Stop": [
        {
          "hooks": [
            {
              "type": "command",
              "command": "echo 'turn ended' >> /tmp/codex.log",
              "statusMessage": "Wrapping up turn...",
              "timeout": 10
            }
          ]
        }
      ]
    }
  }

[etraut-openai]

We're building the hooks infrastructure and working the bugs out with these first two triggers. Once that's stable, it should be easy and quick to add more.

[jpcaparas]

Please allow the option for async hooks. Those would be a game changer as well for invoking long-running test suites without blocking the main session.

[etraut-openai]

I'm not sure what you mean by "async hooks". Hooks are synchronous, but they can invoke arbitrary scripts. If you want your script to start an async task like a long-running test suite, you can do that.

[jpcaparas]

Pretty much something similar to what CC has right now where hooks can be be turned async with a simple config toggle: async: true

[Nabstar3]

We're building the hooks infrastructure and working the bugs out with these first two triggers. Once that's stable, it should be easy and quick to add more.

Thankyou for the update @etraut-openai!

1. Do you have an expected timeline on when this feature would no longer be experiemental?
2. Do you have other ideas for triggers?

[Nabstar3]

Source from: #2109 (comment)

[jialinyi94]

+1

[jianshuod]

+1

[tomismeta]

This would add a lot of value for external clients.

From integrating against App Server, the stream is already rich, but a lot of it is still observational rather than actionable:

• item/started
• item/completed
• item/agentMessage/delta
• thread/status/changed
• turn/completed

What works especially well today is when Codex emits a first-class server request. We’ve live-verified an external-client flow around item/commandExecution/requestApproval where:

• the request opens
• the client surfaces it as a focused decision
• the client responds
• serverRequest/resolved arrives
• the turn resumes cleanly

So from this side, the missing piece feels less like “more stream” and more like “clearer interruption semantics.”

If App Server evolves in this direction, the highest-value additions for external supervisory clients would be a very small set of explicit lifecycle hooks like:

• request.opened
• request.resolved
• turn.blocked
• turn.resumed
• turn.completed

Especially turn.blocked: that would make it much easier to distinguish “Codex is streaming progress” from “Codex is actually waiting on the human now.”

My bias would be to keep this small and high-confidence rather than exposing more low-level item churn.

[dennisonbertram]

+1

[high726]

+1

[andre-menutole]

Looks like it’s implemented, but I’d love it if it could work inside a plugin too, like Claude.

[NWalker4483]

Ditto

[joshturner35654-lang]

👋

…

On Sun, Mar 29, 2026 at 00:39 André Luis ***@***.***> wrote: Looks like it’s implemented, but I’d love it if it could work inside a plugin too, like Claude. — Reply to this email directly, view it on GitHub <#2150?email_source=notifications&email_token=CAJBYVNDXOTXN2M7MLM3ZRD4TBPCLA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNRTGYYTGMJTUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-16361313>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CAJBYVMFEWNHJZYETWD27K34TBPCLAVCNFSM6AAAAACDSEK3VCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMMZWGEZTCMY> . You are receiving this because you commented.Message ID: ***@***.***>

[joshturner35654-lang]

Hey what's up?

…

On Wed, Apr 8, 2026 at 18:30 N. Walker ***@***.***> wrote: Ditto — Reply to this email directly, view it on GitHub <#2150 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CAJBYVIRMCGWLNOSR7LAZS34U2EFFAVCNFSM6AAAAACDSEK3VCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMNBZGI2DCNI> . You are receiving this because you commented.Message ID: ***@***.***>

[Ar9av]

tool use hooks: synchronous vs. asynchronous Pattern

One pattern worth copying from the Claude Code hooks design is distinguish synchronous PreToolUse (can block) from async PostToolUse (observe only).

The blocking hook is the one that actually prevents the Codex branch-name command-injection class of issues - async logging doesn't.

What I feel should be the shape of it:

Input (stdin):

{
  "tool_name": "...",
  "tool_input": {...},
  "session_id": "...",
  "cwd": "..."
}

Output (stdout):

{
  "decision": "allow" | "deny",
  "reason": "..."
}

Exit codes:

• Exit 0 = allow
• Exit 2 = deny

Secret Handling

Secret handling deserves first-class support too: let the hook rewrite tool_input to substitute placeholders (@@SECRET:gh_token@@) with real values only at execution, so the model never sees the raw secret in its transcript. We've been running exactly this pattern in Claude Code via PrismorSec/immunity-agent - happy to share the schema if it's useful input to the design.

---

Disclosure: I maintain Prismor.

[AKclown]

"hooks": {
        "PreToolUse": [
            {
                "matcher": "Edit|Write",
                "hooks": [
                    {
                        "type": "command",
                        "command": "bash ./.codex/protect-files.sh",
                        "statusMessage": "Test Files"
                    }
                ]
            }
        ]
    }

The file itself is protected, and regular patches are blocked. The Codex app uses other methods to modify the protected file.

For example, bash commands bypassed my hooks rules.

How can I implement restrictions on PreToolUse?