TUI-usable session-control primitive in Codex CLI
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-serverdirectly. codex+codex-replyworks only inside the same live MCP server process.thread_idfromcodex exec --jsondoes not continue viacodex-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
- Codex
injectrequest: https://github.com/openai/codex/issues/11415
_Closed as not planned._
- Claude
injectrequest: https://github.com/anthropics/claude-code/issues/24947
_Related request in Claude ecosystem; channel workflow is available there._
- App Server direction post: https://openai.com/index/unlocking-the-codex-harness/
_App Server described as the long-term integration path._
- App Server docs: https://developers.openai.com/codex/app-server
_Current protocol surface for thread/turn/event control._
- CLI reference: https://developers.openai.com/codex/cli/reference
_Current CLI capabilities and limits._
- Release notes with app-server/TUI context:
- https://github.com/openai/codex/releases/tag/rust-v0.117.0
- https://github.com/openai/codex/releases/tag/rust-v0.118.0
- Related limitation report: https://github.com/openai/codex/issues/6168
_codex-reply cannot continue with thread_id from a separate process/session._
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
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
This feature request hasn't received enough upvotes, so I'm going to close it.