Repository navigation
Feature request: official machine-readable event surface for approvals and turn lifecycle #16484
Description
Please provide a supported, machine-readable external event surface for Codex that external tools can consume.
I reviewed these related issues before filing this:
- Event Hooks #2109 Event Hooks
- Support notify for user approval events #3247 Support notify for user approval events
- Add notification for command execution approval prompts #2961 Add notification for command execution approval prompts
- Missing event logs for approval-request #6024 Missing event logs for approval-request
- Feature request: Notifications for approval prompts, job completion, and file saves #3052 Notifications for approval prompts, job completion, and file saves
- Feature request: built-in notifications for CLI responses #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.
Activity
github-actions commentedon Apr 1, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Asuka-wx commentedon Apr 2, 2026
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
s4ndxyz commentedon Apr 2, 2026
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.
Asuka-wx commentedon Apr 2, 2026
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.
dpritchett commentedon Apr 7, 2026
+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.Asuka-wx commentedon Apr 7, 2026
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.
oxysoft commentedon May 8, 2026
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.
gennadi-kuzmin commentedon Sep 30, 2026
I am building a passive local companion and need exact per-thread status
counts across Codex CLI, Desktop and IDE. I checked the generated schema and
runtime sources for Codex 0.159.2.
The existing turn notifications provide terminal outcomes, but a thread list
or one app-server's loaded-thread registry does not establish a complete
cross-process runtime snapshot. I also could not find a documented per-turn
presentation/acknowledgement state. Reading a thread through RPC must not be
treated as showing its result to the user.
Could you confirm the supported integration path for these two requirements?
Desktop and IDE threads, with opaque thread/turn identities, explicit
working and completed/failed/interrupted outcomes, source epoch/revision,
completeness and reconnect reconciliation. Unknown or incomplete coverage
must be distinguishable from an authoritative empty snapshot.
live changes, so a reconnecting observer can distinguish a pending result
from one already presented. “Presented” should mean a documented renderer
fact, never that a person read or understood the result. The observer should
not be able to write this acknowledgement.
No prompts, result text, paths, commands, diffs, account details or UI telemetry
are needed. The observer must not start, resume, steer, interrupt or answer
anything. New activity, idle state and transport errors are not outcome or
acknowledgement signals.
If an existing supported API covers this, pointers would help. Otherwise,
would you prefer a focused lifecycle contribution here and a separate
presentation-contract proposal, or another integration channel? I am keeping
exact live counts unavailable until the source's authority is established.