Feature request: official machine-readable event surface for approvals and turn lifecycle
Please provide a supported, machine-readable external event surface for Codex that external tools can consume.
I reviewed these related issues before filing this:
- #2109 Event Hooks
- #3247 Support notify for user approval events
- #2961 Add notification for command execution approval prompts
- #6024 Missing event logs for approval-request
- #3052 Notifications for approval prompts, job completion, and file saves
- #4491 built-in notifications for CLI responses
This request is not for another built-in notification backend, and it is not just "notify on approval prompts".
The gap I am trying to describe is that external integrations currently need to infer important events from internal persisted artifacts rather than consume a documented external contract.
A useful minimum event set would be:
- turn started
- turn completed
- turn interrupted
- exec approval requested
- patch approval requested
- explicit user interaction requested
The exact transport is up to the team: expanded hooks, app-server notifications, or another official event interface would all solve the problem. The important part is that it is supported and documented, so users can build their own integrations without depending on internal storage details.
This would enable user-built integrations such as:
- desktop or mobile notifications
- webhooks / chatops bridges
- local automation
- observability tooling
Non-goal:
I am not asking Codex core to ship a specific downstream backend such as Bark, Slack, Telegram, etc. A stable event contract would already solve the main problem.
Ideally this should work consistently across Codex surfaces, since the same integration need shows up in CLI, IDE extensions, and other clients.
The app-server already documents turn lifecycle notifications, so this seems closer to exposing or standardizing an external integration path than inventing an entirely new capability.
If this should be tracked under #2109 instead of as a separate issue, that is fine.
The main thing I am asking for is clarity on the supported path for non-UI integrations:
- expanded hooks,
- app-server notifications,
- or another official external event surface.
Right now the practical workaround is to watch internal persisted state and reconstruct events from it, which works for personal tooling but is brittle as a long-term integration strategy.
7 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
This is the exact problem I'm working around. My codex-telegram-bridge currently reads tmux pane output to infer events. A stable event contract would make this much cleaner. Here's what I built as a workaround：
Turn local Codex sessions on macOS into a Telegram control surface you can actually use from your phone.
https://github.com/Asuka-wx/codex-telegram-bridge
One-line positioning:
Keep your existing ssh + tmux + Codex workflow, and use Telegram only as the remote layer for status, approvals, and follow-up input.
Why It Matters
No workflow rewrite: keep using local tmux + Codex instead of switching to a browser dashboard or remote desktop
Actually remote-usable: not just logs, but approvals, interrupts, and follow-up input
Clear multi-task control: one control topic plus task-specific topics for parallel work
Phone-friendly by design: useful when you are away from your machine but still need to keep work moving
Lower setup friction: one-command installer plus launchd service support
Thanks — this is a very helpful concrete example of the same gap.
Your bridge is a good illustration of why this ideally should be solved above any single runtime surface. Right now the workaround is tied to CLI / tmux-specific signals, but the same underlying need also shows up in CLI, VS Code / IDE clients, and other app-server-backed surfaces whenever users want remote status, approvals, or follow-up input.
That is exactly the part I hope Codex can make easier: not a built-in Telegram/Bark-specific integration, and not something tied to one surface only, but a supported external event contract that tools can build on cleanly across Codex surfaces.
Totally agree — a stable external event contract would be the ideal foundation. My bridge currently works around the gap by reading
~/.codex/sessionsand using tmux as the I/O channel, which works but is inherently surface-specific.If Codex ships a cross-surface event hook (like what's discussed in #16484), I'd be happy to refactor the bridge to consume it. That would make it cleaner and also support IDE/app-server scenarios, not just CLI+tmux.
In the meantime, this bridge is a working solution for CLI users who need mobile control today.
+1, but my main need is observability, not external auto-approve. I want a stable machine-readable signal 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.What you described is indeed a very real need, but since the official support isn't available right now, I'll use my method. Because the built-in silent mode allows for receiving important information via Telegram, such as the approval signal alerts you mentioned, it's quite simple, as this is a native Telegram capability.
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.