Fix Codex reviewer launch probe so same-family review can run #791

New issue

Closed

opened 2026-07-09 09:08:46 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-07-09 09:08:46 +00:00

Member

Problem

A Codex worker hit the review gate after CI, but the Codex reviewer family did not actually run. The panel dropped every candidate and failed closed:

Dropped: codex (unavailable: codex launch probe failed (exit -1): Reading additional input from stdin... OpenAI Codex v0.142.5 -------- workdir: /workspace/factory-game-v3 model: gpt-5.4 provider: openai approval: never sandbox: danger-full-access reasoning effort: none reasoning summaries: none session id: 019f460f-d244-7660-accb-12baf26297a4 -------- user Reply with exactly ok.); claude (...); opencode (...); goose (...)
panel BLOCKED: 0/0 passing - do NOT land this diff.

The wording contradiction is tracked separately in ward#790. This issue is the more important failure: the intended reviewer family was present enough to launch and print a Codex banner, but the smoke probe still failed before review could run.

Why this matters

The review gate relies on at least the worker family being runnable inside the worker container. If Codex cannot pass the in-container launch probe, Codex engineers cannot get a same-family review even when the binary and token are present. That turns normal landing into an environment block rather than a code-quality signal.

Initial read

The observed probe output suggests the current Codex CLI entered an interactive/stdin-reading path during the Reply with exactly ok. smoke test instead of completing as a non-interactive headless check. The engineer should verify whether this is caused by the argv shape, stdin handling, timeout behavior, model/config selection, or Codex CLI behavior change.

Relevant surfaces:

cmd/ward/agent_review.go - reviewerAvailable, reviewerRunCtx, and reviewer runner wiring.
Codex launch-gate implementation under internal/agents.
Tests covering launch probes and headless argv for Codex.
docs/dispatch-review.md if the operator-facing recovery guidance changes.

Do

Reproduce the Codex launch-probe failure in a container with current Codex CLI behavior.
Identify why the smoke test prints Reading additional input from stdin... and does not return a usable ok.
Fix the Codex review availability probe or headless invocation so a valid Codex environment is marked runnable.
Keep genuine auth/startup failures loud and actionable.
Add regression coverage for the failing Codex smoke-test shape. A probe that reaches the Codex banner and then waits for stdin should not collapse into an opaque exit -1 without recovery guidance.

Acceptance

A Codex worker container with working Codex credentials can pass the Codex reviewer launch probe.
A broken Codex environment still fails closed with an actionable reason.
The reproduced Reading additional input from stdin... failure has a targeted test or fixture.
ward exec test passes.

Dispatch note

Dispatch this with --skip-review until the review gate is healthy enough to review its own repairs.

## Problem A Codex worker hit the review gate after CI, but the Codex reviewer family did not actually run. The panel dropped every candidate and failed closed: ```text Dropped: codex (unavailable: codex launch probe failed (exit -1): Reading additional input from stdin... OpenAI Codex v0.142.5 -------- workdir: /workspace/factory-game-v3 model: gpt-5.4 provider: openai approval: never sandbox: danger-full-access reasoning effort: none reasoning summaries: none session id: 019f460f-d244-7660-accb-12baf26297a4 -------- user Reply with exactly ok.); claude (...); opencode (...); goose (...) panel BLOCKED: 0/0 passing - do NOT land this diff. ``` The wording contradiction is tracked separately in ward#790. This issue is the more important failure: the intended reviewer family was present enough to launch and print a Codex banner, but the smoke probe still failed before review could run. ## Why this matters The review gate relies on at least the worker family being runnable inside the worker container. If Codex cannot pass the in-container launch probe, Codex engineers cannot get a same-family review even when the binary and token are present. That turns normal landing into an environment block rather than a code-quality signal. ## Initial read The observed probe output suggests the current Codex CLI entered an interactive/stdin-reading path during the `Reply with exactly ok.` smoke test instead of completing as a non-interactive headless check. The engineer should verify whether this is caused by the argv shape, stdin handling, timeout behavior, model/config selection, or Codex CLI behavior change. Relevant surfaces: * `cmd/ward/agent_review.go` - `reviewerAvailable`, `reviewerRunCtx`, and reviewer runner wiring. * Codex launch-gate implementation under `internal/agents`. * Tests covering launch probes and headless argv for Codex. * `docs/dispatch-review.md` if the operator-facing recovery guidance changes. ## Do * Reproduce the Codex launch-probe failure in a container with current Codex CLI behavior. * Identify why the smoke test prints `Reading additional input from stdin...` and does not return a usable `ok`. * Fix the Codex review availability probe or headless invocation so a valid Codex environment is marked runnable. * Keep genuine auth/startup failures loud and actionable. * Add regression coverage for the failing Codex smoke-test shape. A probe that reaches the Codex banner and then waits for stdin should not collapse into an opaque `exit -1` without recovery guidance. ## Acceptance * A Codex worker container with working Codex credentials can pass the Codex reviewer launch probe. * A broken Codex environment still fails closed with an actionable reason. * The reproduced `Reading additional input from stdin...` failure has a targeted test or fixture. * `ward exec test` passes. ## Dispatch note Dispatch this with `--skip-review` until the review gate is healthy enough to review its own repairs.

coilyco-ops commented

2026-07-09 09:09:13 +00:00

Author

Member

🔒 Reserved by ward agent --harness codex — container engineer-codex-ward-791 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-09T09:09:11Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (1h TTL); --force overrides.

Do not comment on or edit this issue to steer the run while it is reserved. The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a new issue, dispatched fresh — that is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).

run seed context — what this run is carrying (ward#609)

Resolved: coilyco-flight-deck/ward#791 · branch issue-791 · harness codex · workflow pr
Run: engineer-codex-ward-791 · ward v0.488.0 · dispatched 2026-07-09T09:09:11Z
Comment thread: 0 included in the pre-flight read, 0 stripped (ward's own automated comments).

Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.488.0).

— Codex, via ward agent

🔒 Reserved by `ward agent --harness codex` — container `engineer-codex-ward-791` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-09T09:09:11Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (1h TTL); `--force` overrides. **Do not comment on or edit this issue to steer the run while it is reserved.** The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a **new issue, dispatched fresh** — that is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494). <details><summary>run seed context — what this run is carrying (ward#609)</summary> - **Resolved:** `coilyco-flight-deck/ward#791` · branch `issue-791` · harness `codex` · workflow `pr` - **Run:** `engineer-codex-ward-791` · ward `v0.488.0` · dispatched `2026-07-09T09:09:11Z` - **Comment thread:** 0 included in the pre-flight read, 0 stripped (ward's own automated comments). Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.488.0). </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from a pull request that will close it,

2026-07-09 09:18:11 +00:00

Fix Codex reviewer launch probe so same-family review can run #796

coilyco-ops commented

2026-07-09 09:22:34 +00:00

Author

Member

WARD-OUTCOME: done - Codex smoke probe now feeds the prompt on stdin with codex exec -, so same-family review can launch again.
workflow: pr; review summary: skipped by --skip-review / --no-review-gate.
The fix was straightforward, but Codex's stdin behavior was noisier than expected, and the first PR run failed on a lint wrapper before I trimmed it back. Confidence is high; the remaining rough edge was the prompt transport, not the review logic.

WARD-OUTCOME: done - Codex smoke probe now feeds the prompt on stdin with `codex exec -`, so same-family review can launch again. workflow: pr; review summary: skipped by --skip-review / --no-review-gate. The fix was straightforward, but Codex's stdin behavior was noisier than expected, and the first PR run failed on a lint wrapper before I trimmed it back. Confidence is high; the remaining rough edge was the prompt transport, not the review logic.