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

[Gbenga238]

+1

[fstepho]

+1

[sychen23]

+1

[tomastoth4]

+1

[shubhamgupta731]

+1

[lespaceman]

App Server is what you all need: https://developers.openai.com/codex/app-server

[Floriferous]

Could you give an example for how to set it up?

[danias]

@etraut-openai

Claude Code, Gemini, Cursor, GitHub Copilot OpenCode all offer hooks that enable rich AI-native development workflows. Basically, all except Codex. Please look into it. I am happy to contribute a design (and even the implementation) for how this could be done in this CLI if you are interested.

Please note that it would be very useful, as Cursor did by supporting hooks in both its CLI and IDE, to also add hooks to the macOS Codex app, not just the CLI. Of course, starting at least with the CLI would be a fantastic first step.

[Nabstar3]

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

[danias]

Thanks @Nabstar3 that's great news!

[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
            }
          ]
        }
      ]
    }
  }

[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?

[waki285]

I'm not sure what you mean by "async hooks".

This is a hook that moves on to the next task before the hook's execution finishes, akin to Claude Code's "async": true.

While async hooks would not be able to modify or block the behavior of the main task if hooks like PreToolUse that can do so were added in the future, they would still remain useful.

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