Feature request: deliver external/async events as turns into a live (visible) session — today only headless remote-control threads are reachable

Open 💬 2 comments Opened Jul 16, 2026 by Lzzzs

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

Codex has no supported way for an external, asynchronous event (a file-watcher signal, a webhook, an incoming message/notification) to wake a running, user-visible session and inject a turn into it. External injection through the remote-control daemon only drives headless threads, which never surface in the desktop app window or a foreground codex TUI the user is actually watching.

The transport pieces already exist (remote-control + thread/start + turn/start) — they just can't target the session a human has open.

What I observed (why it isn't possible today)

macOS (Apple Silicon), Codex CLI 0.140.x with managed app-server 0.142.x, verified on a real machine via live process inspection + WS-over-unix RPC:

The visible desktop app's backing app-server runs as a private stdio subprocess with no listening socket:

/Applications/Codex.app/Contents/Resources/codex app-server --listen stdio://
→ nothing external can connect to it.

The only externally reachable endpoint is a separate remote-control daemon:

codex … --remote-control --listen unix://…/app-server-control/app-server-control.sock

thread/start + turn/start over WS-over-unix to that control socket does wake an idle headless thread and run a full turn (observed turn/started → streamed item/agentMessage/delta → turn/completed, real assistant output).
But that headless thread lives in a different process / thread-store than the desktop window (confirmed with distinct live PIDs for the window's app-server vs. the injectable daemon). The injected turn never appears in the window the user is looking at.

Net: you can wake a headless agent, but not the session you have open. There is no --listen/attach option that both (a) serves a visible interactive session and (b) is reachable by an external turn/start.

What I'm asking for

Any one of these would close the gap:

An opt-in flag to expose a live interactive session (desktop app or codex TUI) on the remote-control endpoint, so an external turn/start is delivered as a new turn in that session.
Let the desktop app / TUI attach to the remote-control daemon's thread-store (shared threads), so a headless-injected turn surfaces in the visible window.
A first-class "external wake" primitive — the model Claude Code's Monitor tool already provides: you register a long-lived watcher process, and each line it emits on stdout becomes an asynchronous user-turn in the live session. Codex has the injection transport (turn/start) but no equivalent way to bind a watcher to the session the user is watching.

Motivation

Event-driven automation often needs to wake the session the user is actively watching when something happens outside Codex — a file changes, a webhook fires, a message arrives — and have the agent pick it up as a new turn without the user re-prompting. Today the only externally wakeable target is an invisible headless thread, so any such flow has to run where the user can't see it. A supported wake path for live sessions would remove that limitation.

Environment

Codex CLI 0.140.x, managed app-server 0.142.x
macOS (Apple Silicon)
Observed 2026-07 on a real machine.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#32445

Powered by Codex Action

ctut · 1 month ago

Adding a concrete macOS accessibility/productivity use case that matches this request.

The user wants a bare Fn push-to-talk helper: holding Fn records locally, releasing it transcribes, and the resulting text is delivered into the same visible Codex Desktop thread they are already using. If any other key or modifier is pressed, capture is abandoned and the original key combination continues to its normal macOS/application handler unchanged.

The capture and transcription side can be built without UI automation. The blocker is safe delivery into the live Desktop session. A separate app-server can create or resume its own control context, but that does not prove delivery into the exact in-flight session visible to the user.

For this workflow, a supported bridge would ideally provide these properties:

The target thread is prebound by the Desktop-side integration rather than supplied with each request.
Start-versus-steer selection occurs atomically inside the app process using current live state and the exact active turn identity.
Each capture has one idempotency identity; duplicate and ambiguous acknowledgements never cause automatic resend.
The local helper is authenticated through a narrow owner-private endpoint rather than by process name or a self-declared client type.
External input remains ordinary user input and does not grant approvals, permissions, or execution authority.
No Accessibility typing, clipboard injection, synthetic Return key, private IPC reverse engineering, or second competing app-server is required.

We have intentionally held activation of the otherwise feasible capture/transcription half because presenting it as complete without a supported live-session bridge would be misleading. An opt-in live-session attachment or fixed-target external-wake primitive would unblock this use case cleanly.