›_ Codex Issues
Codex Issues / #22003

Support injecting command output from background completion into the active Codex session

Open 💬 7 comments Opened May 10, 2026 by harshitsinghbhandari
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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.

View original on GitHub ↗

7 Comments

harshitsinghbhandari · 2 months ago

Additional environment details from the repro run:

  • Platform: Darwin 25.4.0 (arm64)

The key behavior observed was that a background watcher could complete, but the active Codex session did not receive a spontaneous wake-up or injected turn; I had to explicitly poll the running session to observe the output.

github-actions[bot] contributor · 2 months ago

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

  • #20475
  • #21551

Powered by Codex Action

harshitsinghbhandari · 2 months ago

Not a Duplicate.

harshitsinghbhandari · 2 months ago

@etraut-openai Will this be worked on?

fl4p · 26 days ago

I ran into the same need while testing file/channel-watch workflows where a background command blocks on an event source and should wake Codex when it emits output.

I put together a discussion branch with one concrete implementation sketch:

https://github.com/fl4p/codex/tree/feat/wake-on-background-output

High-level behavior in the branch:

  • Adds an opt-in wake_on_output boolean to unified exec_command.
  • Existing behavior stays unchanged by default.
  • When enabled, output emitted after the initial exec_command tool call has yielded is batched and delivered as a bounded synthetic user message.
  • The injected terminal output is marked as untrusted data.
  • Each wake payload is capped at 4 KiB to avoid unbounded context injection from noisy processes.

Local validation on that branch:

  • just fmt passed
  • just fix -p codex-core passed
  • just test -p codex-core wake_on_output passed
  • just test -p codex-core background_output_wake passed
  • just test -p codex-core shell_spec passed

I also opened #29865 before finding this issue; I’m closing that one as a duplicate and leaving the patch link/details here instead.

yaanfpv · 26 days ago

I ran into this same gap and ended up building the tool-shaped version of it, so sharing here since this looks like where it's converging.

Instead of a flag on exec_command (#29865) or a generic injection path, I added an agent-callable monitor tool: the model runs a shell command as a background watcher with action=start/stop/list, and each line it prints (stdout or stderr) wakes the idle session and starts a turn. While the watch is quiet the session makes no API calls. It is the same core seam everyone in this thread is describing: background output delivered as a bounded, untrusted synthetic user message through the session's existing idle-start path, only when the session can take it. No protocol change, and the watcher is just a normal sandboxed unified_exec process, so it inherits the existing approval/sandbox/shell handling.

The difference from the flag form is that it is a tool the model reaches for and drops mid-task (named, ephemeral watches it manages via a small per-session registry), rather than a property of one exec call.

I have a working reference and I have been running it live in my own Codex, both the CLI and the Desktop app. It is feature-gated, off by default. Full diff, one commit on the v0.142.0 tag: https://github.com/openai/codex/compare/rust-v0.142.0...yaanfpv:codex:monitor-tool. It carries tests (eight integration plus two unit, clean under fmt and clippy) and a few output-safety bounds (line and byte flood guards, and no silently dropped notifications).

I wrote the full design up as #29922. Happy to fold it in here if this is the better home, and glad to open a PR if the approach is useful.

ilyes-i-ben · 18 days ago

+1