codex - 💡(How to fix) Fix Support injecting command output from background completion into the active Codex session [4 comments, 2 participants]

Is Codex missing a feature that you'd like to see? Feel free to propose it here.

Before you submit a feature:

1. Search existing issues for similar features. If you find one, it rather than opening a new one.
2. The Codex team will try to balance the varying needs of the community when prioritizing or rejecting new features. Not all features will be accepted.

See Contributing for more details.

What variant of Codex are you using?

CLI

What feature would you like to see?

Support a command-response injection path for background completions so an external watcher or orchestrator can deliver the completed command's output directly into the active Codex session as the next user turn, without requiring tmux send-keys or explicit polling. The intended workflow is:

• a background process watches an inbox file or similar event source
• when new output arrives, the watcher exits or emits a completion event
• Codex receives that output as input automatically in the active conversation context
• the session can then act on the injected content and continue the loop

This would make file-based or socket-based orchestration possible for agents that should wake Codex on process completion.

Additional information

I tested a file-watcher prototype where a background process writes JSONL output after new content arrives. In the current harness, the session does not wake up on its own when the watcher exits; output only appears after an explicit poll. A command-response injection mechanism would remove the need for tmux-driven key injection and make event-driven orchestration much cleaner.