Summary
The managed codex A2A receiver fails every turn against the installed codex-cli 0.136.0. The peer deploys, wires into fleet.yaml, appears in the dashboard/Matrix3D, and receives messages — but the actual codex exec invocation returns rc=1 with no parseable output, so the peer never replies. Observed in the dashboard thread:
[error] codex exited rc=1 with no parseable output: Reading additional input from stdin...
Discovered during end-to-end QA of the mode-aware dashboard (switchui Matrix3D NousResearch#183). Visualization/routing are correct — this is purely the receiver's CLI invocation.
Environment
- a2a_fleet plugin v0.8.6 (installed
~/.hermes/hermes-agent)
- codex-cli 0.136.0 (
codex --version)
- Receiver template documents the contract for codex-cli 0.135.0 (
templates/codex_receiver.py lines 27-35, 303-322)
Root cause (likely): exec arg-contract drift 0.135 → 0.136
templates/codex_receiver.py builds the turn argv with the prompt as a positional arg:
# first turn (line ~321)
cmd = ["codex", "exec", full_prompt, "-s", sandbox]
# resume turn (line ~318)
cmd = ["codex", "exec", "resume", thread_id, full_prompt]
…and runs it via _subprocess_runner (Popen, line ~595). The template even pre-documents the stderr line as benign for 0.135.0:
# line ~601
# stderr note: codex writes "Reading additional input from stdin..." to stderr
On 0.136.0 that stderr line is no longer benign — it accompanies rc=1 + empty/unparseable stdout, which the receiver surfaces as the error above. This strongly suggests codex exec in 0.136 either:
- no longer accepts the prompt as a bare positional (now expects it on stdin or behind a flag), so the process blocks/errors waiting on stdin, or
- changed the
--json event stream so the "last item.completed / agent_message" parse (lines ~44) yields nothing.
Repro
- Deploy the codex receiver into a repo (
deploy_codex_receiver, repo /Users/rohits/.hermes/hermes-agent).
fleet_send any message to the codex peer (e.g. "Reply with only the word PONG").- Dashboard thread shows
[error] codex exited rc=1 with no parseable output: Reading additional input from stdin...; no reply is produced.
Suggested investigation / fix
- Diff
codex exec --help between 0.135.0 and 0.136.0 — confirm whether the prompt positional was removed / stdin became required.
- If stdin is now the input channel: pass
full_prompt via Popen.communicate(input=...) instead of argv, and ensure _subprocess_runner wires stdin=PIPE (currently the stdin note implies stdin isn't fed).
- If only the
--json event schema changed: update the final-reply parser (template lines ~36-47) to the 0.136 event shape.
- Re-pin/verify the documented "Subprocess CLI contract" version in the template + add a
codex --version compat check in _probe_codex_cli() (currently only checks presence, codex_deploy.py:337) that warns on an untested major/minor.
- Add a smoke test under
tests/plugins/a2a_fleet/ that runs one real codex exec turn and asserts a parseable reply, gated on codex-cli availability.
Impact
Codex managed mode is non-functional for replies on the current CLI — it appears in the fleet but every turn errors. cc receivers are unaffected (different CLI). Medium severity (feature-degraded, no data loss, clear error surface).
Summary
The managed codex A2A receiver fails every turn against the installed codex-cli 0.136.0. The peer deploys, wires into
fleet.yaml, appears in the dashboard/Matrix3D, and receives messages — but the actualcodex execinvocation returns rc=1 with no parseable output, so the peer never replies. Observed in the dashboard thread:Discovered during end-to-end QA of the mode-aware dashboard (switchui Matrix3D NousResearch#183). Visualization/routing are correct — this is purely the receiver's CLI invocation.
Environment
~/.hermes/hermes-agent)codex --version)templates/codex_receiver.pylines 27-35, 303-322)Root cause (likely): exec arg-contract drift 0.135 → 0.136
templates/codex_receiver.pybuilds the turn argv with the prompt as a positional arg:…and runs it via
_subprocess_runner(Popen, line ~595). The template even pre-documents the stderr line as benign for 0.135.0:On 0.136.0 that stderr line is no longer benign — it accompanies rc=1 + empty/unparseable stdout, which the receiver surfaces as the error above. This strongly suggests
codex execin 0.136 either:--jsonevent stream so the "lastitem.completed/agent_message" parse (lines ~44) yields nothing.Repro
deploy_codex_receiver, repo/Users/rohits/.hermes/hermes-agent).fleet_sendany message to thecodexpeer (e.g. "Reply with only the word PONG").[error] codex exited rc=1 with no parseable output: Reading additional input from stdin...; no reply is produced.Suggested investigation / fix
codex exec --helpbetween 0.135.0 and 0.136.0 — confirm whether the prompt positional was removed / stdin became required.full_promptviaPopen.communicate(input=...)instead of argv, and ensure_subprocess_runnerwiresstdin=PIPE(currently the stdin note implies stdin isn't fed).--jsonevent schema changed: update the final-reply parser (template lines ~36-47) to the 0.136 event shape.codex --versioncompat check in_probe_codex_cli()(currently only checks presence,codex_deploy.py:337) that warns on an untested major/minor.tests/plugins/a2a_fleet/that runs one realcodex execturn and asserts a parseable reply, gated on codex-cli availability.Impact
Codex managed mode is non-functional for replies on the current CLI — it appears in the fleet but every turn errors. cc receivers are unaffected (different CLI). Medium severity (feature-degraded, no data loss, clear error surface).