Add `codex inject` to send prompts to existing sessions (automation + orchestration)

Resolved 💬 3 comments Opened Feb 11, 2026 by Prathyushmnchla Closed Feb 12, 2026

💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What variant of Codex are you using?

CLI

What feature would you like to see?

• Title
Add codex inject to send prompts to existing sessions (automation + orchestration)

### Summary
Please add a direct CLI command to inject a user message into an existing Codex session from outside the TUI.

Current workflow for external automation is awkward (codex resume ... "prompt").
### Core CLI Proposal
``bash codex inject <session_name_or_id> --text "..."`Also accept alias:`bash codex inject <session_name_or_id> --text_file /path/to/prompt.txt``

### Expected Behavior

If the target session is running: append the message as a new user turn.

### Example Use Cases
#### End-of-Train Script
``bash codex inject <session_name> --text "Training finished. Read logs/train.log and propose next run config."``

#### Coder-Architect Pattern
```bash
# Architect -> Coder
codex inject <coder_session_name> --text "Implement API pagination for /v1/items and add tests."

# Coder -> Architect
codex inject <architect_session_name> --text "Implementation complete on branch feat/pagination. Review diff and propose follow-up refactors."
```

#### CI Failure Triage
``bash codex inject <session_name> --text "CI failed on test_auth_refresh. Read latest test logs and propose minimal fix."``

### CLI Enhancements (Future)

--hook-name <name> for automation/audit labels.
--text - (stdin support).
Delivery control: --queue (default) and --interrupt.
Session behavior flags: --resume, --create-if-missing, --if-running.
Scriptability: --json, --wait, --timeout.
Reliability: --idempotency-key + replay protection.
Safety: --dry-run preflight output.
Access/security: session ownership checks, authenticated caller checks, and encrypted local transport for injection requests.
Optional local automation listener backend (socket/localhost port), while keeping codex inject as the primary UX.

### Scope
Cross-platform CLI feature (Linux/macOS/Windows), independent of shell or terminal multiplexer.

### Note
Drafted by Codex (AI assistant).

Additional information

_No response_

View original on GitHub ↗

3 Comments

ignatremizov · 6 months ago

I'm 85% sure you can pass a prompt to an existing session via codex exec already. Also sessions inject skill files if the skill tokens ($skill-name) are present. Finally there is codex app-server and the JSON RPC API so you can integrate a third party tool for orchestration.

etraut-openai contributor · 6 months ago

The CLI (TUI) is intended for interactive use, not for automation scenarios.

The CLI can be started in non-interactive mode (codex exec) for automation scenarios, but that runs synchronously from the perspective of the caller, so I don't think it makes sense to "inject" (or "steer", as we refer to it) when using codex exec.

If you want to create automations with a long-lived session and support operations like "steer", I recommend using our app server mechanism. It supports a turn/steer call. You can read more about the app server mechanism in this recent blog post.

Prathyushmnchla · 5 months ago

This comment was drafted by Codex after my user asked me to evaluate the App Server suggestion against his actual workflow.

After thinking it through, I do not think this is a small wrapper around turn/steer, or something that can be recreated in ~500 LOC in a clean, maintainable way.

To feel like a real CLI feature, codex inject-style behavior would also need session addressing, queue vs interrupt semantics, idle vs active turn handling, security/ownership boundaries, and a way for the existing TUI session to visibly pick up the injected message while preserving the normal CLI coding workflow.

So while App Server exposes the lower-level steering primitive, it does not really replace the missing CLI capability. It shifts the work onto the user to rebuild orchestration and session behavior around App Server just to regain what the CLI already does well.

That is why “use App Server” feels unsatisfying here. The gap is still real: lightweight external messaging into an existing interactive Codex session would be genuinely useful for multi-session coding, long-running jobs, and architect/coder workflows.