TUI-usable session-control primitive in Codex CLI

Resolved 💬 3 comments Opened Apr 8, 2026 by Prathyushmnchla Closed May 10, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What variant of Codex are you using?

Codex CLI

What feature would you like to see?

I know this overlaps with my earlier request, but this is a narrower ask and the workflow need is real for me.

My prior codex inject request (#11415) was closed as not planned.
I am not asking to revive that exact command. I am asking for the underlying capability in Codex: a native, App Server–aligned way to send/stream control messages to active sessions. If easier, this could also be done by extending MCP-trigger capabilities.

Practical context: in Claude, channel-style external messaging workflows are already usable, and I can stream inputs and adjust training hyperparameters live in a loop. OpenCode has this workflow too, so switching is a practical alternative. Otherwise, in Codex, achieving the same behavior means building a custom JSON-RPC client and reimplementing session-control plumbing outside native TUI/CLI.

Request

Please expose a first-class, TUI/CLI-usable session-control/channel primitive in Codex with functionality equivalent to the Claude channel workflow, implemented however you think is best.

I do not need a full orchestration framework—just this control path directly from TUI/CLI.

What we tried

  • Tested codex mcp-server directly.
  • codex + codex-reply works only inside the same live MCP server process.
  • thread_id from codex exec --json does not continue via codex-reply (Session not found for thread_id).
  • In Claude, the development-channel path proactively wakes the TUI session when external messages arrive.

So this request is specifically for a native Codex CLI control/wake path for active sessions.
Perhaps an MCP-server-routed external trigger could wake a waiting TUI session.

Drafted by Codex

Additional information

References

_Closed as not planned._

_Related request in Claude ecosystem; channel workflow is available there._

_App Server described as the long-term integration path._

_Current protocol surface for thread/turn/event control._

_Current CLI capabilities and limits._

_codex-reply cannot continue with thread_id from a separate process/session._

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 4 months ago

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

  • #16060
  • #16447
  • #15504
  • #16869

Powered by Codex Action

Prathyushmnchla · 4 months ago

I reviewed the suggested issues. #16447 is the closest and likely solves most of this (local session messaging/injection via UDS).

I’m keeping this open because my request is slightly different: I’m asking for this by extending existing Codex MCP/TUI-accessible primitives (or an App Server-aligned equivalent), with explicit wake/control behavior for waiting TUI sessions.

If maintainers prefer, I’m also happy to fold this into #16447 and track it there.

Drafted by Codex

etraut-openai contributor · 3 months ago

This feature request hasn't received enough upvotes, so I'm going to close it.