What feature would you like to see?

Expose an opt-in local ingress for interactive Codex CLI/TUI sessions, so another trusted local process can safely deliver input to the active session using real session semantics rather than PTY/keyboard emulation.

This is intentionally narrower than broad “remote control” and broader than “support one MCP notification”. The need is:

I have an already-running interactive Codex CLI/TUI session on my machine. I want a trusted local controller to hand it structured work or a follow-up message without pretending to be a keyboard.

Why this matters

Today, local orchestration around a running Codex TUI session often falls back to terminal injection:

• send-keys
• paste-buffer
• pipe-pane -I
• direct PTY writes

These all have the same class of problems:

• text can land in the draft without actually submitting
• injected text can race with a human actively typing
• attribution, dedupe, and replay are ad hoc
• wrappers are forced to emulate terminal input instead of using real session/thread semantics

In practice this makes local automation brittle. It also discourages safer local integrations because the only widely available option is “pretend to be the terminal”.

This matters for:

• local orchestrators coordinating multiple Codex/CLI workers
• tmux- or terminal-based multi-agent workflows
• editor/terminal wrappers
• accessibility tooling
• local remote-control shells
• background workers that need to hand work back to a human-visible Codex session

Why existing features are close, but not enough

Codex already has the right conceptual model in the programmable surfaces:

• thread/start
• thread/resume
• thread/fork
• turn/start
• turn/steer
• turn/interrupt

Those are exactly the kinds of semantics local controllers want.

The gap is that there does not appear to be a supported way to apply equivalent semantics to an already-running interactive Codex CLI/TUI session on the same machine.

Current adjacent features do not fully solve this:

• App Server / SDK: strong control model, but they do not obviously provide a documented “attach this existing interactive TUI session as a local controllable endpoint” workflow.
• MCP: great tool plane, but not a documented receive-side transport into the active TUI thread.
• Event hooks / notify: useful for observation and orchestration, but outbound-only.
• Remote control / mobile proposals: related, but they target remote supervision/control rather than the local trusted-controller case.

What I expected

At least one supported local-first path such as:

1. An opt-in local IPC listener for interactive sessions

   • for example: codex --listen uds:///path/to/session.sock
   • local-only by default
   • receives real turn/draft/steer operations instead of raw keystrokes

2. A local CLI control command for live interactive sessions

   • for example: codex tui send --session <id> --text "..." [--submit]
   • optionally --append-draft, --steer, or --interrupt

3. A documented way to bind an interactive TUI session to App Server semantics

   • so a local controller can attach to the same session/thread and send real turns

What I observed

For the stock interactive CLI/TUI, the practical fallback today is still terminal input emulation.

That leads to concrete failure modes:

• draft text inserted but not submitted
• active human typing gets mixed with injected content
• no built-in sender identity or audit trail at the ingress point
• orchestrators need terminal-state heuristics instead of stable session APIs

Why this is worth solving

This would unlock a cleaner class of local integrations without forcing people into cloud- or network-oriented remote-control flows.

Benefits:

• safer local orchestration for long-running interactive sessions
• less pressure to build wrappers around PTY injection
• easier composition with local tools and terminal multiplexers
• better accessibility and automation ergonomics
• stronger alignment between the interactive TUI and the documented thread/turn model already present in App Server / SDK

Suggested direction

My strong preference would be:

• keep it opt-in
• keep it local-only by default
• reuse existing thread/turn semantics where possible
• avoid introducing a second unrelated message model just for the TUI

If full ingress is too large, a useful partial step would be richer documented local event coverage for orchestration wrappers, for example:

• turn-started
• turn-interrupted
• approval-requested
• approval-resolved
• idle
• draft-presence-changed

That would at least let local controllers make safer delivery decisions without scraping terminal output.

Related issues

This feels related to, but distinct from:

• #15299 inbound MCP notifications into an active CLI session
• #14722 sync CLI and app-server sessions
• #15320 app-server TUI not fully reflecting external live turns on shared thread
• #14693 no-interrupt typing / queued-draft safety while Codex is running
• #9224 remote control from phone/web
• #2109 event hooks

The difference here is the focus on trusted local ingress for an already-running interactive session, without relying on PTY injection and without requiring a separate remote/mobile product surface.

Additional information

If useful, I can provide a more explicit repro matrix showing:

• PTY injection behavior today
• the specific failure modes in interactive terminal workflows
• the minimal event/ingress API surface needed by a local orchestrator