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

Start by tracing the remote-control daemon and the thread/start and turn/start entry points, comparing them with the visible app-server launched via stdio://. Done means an external event can deliver a turn to the user's open desktop or TUI session and its progress is visible there through a supported wake or attachment path.

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:

1. 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.
2. 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.
3. 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.