[bug] Every Codex turn exited 1 and the session still reported alive/ready/idle — a non-zero engine exit is a line of prose in the pane and nothing else

[serge-ivo]

Every Codex turn on this session exited 1, and the platform reports the session healthy

Feedback row 6a84f09a-821f-4ca2-9e8d-fbc8bae1d0fb (2026-08-12 12:16:52, trace eee50f1f,
instance a1d3522f-6b91-4cd9-bf7b-380e470192b7), filed by the agent through record_feedback:

"When starting Codex engine, it doesn't work — the Coding tab shows 'no output yet' and the engine
doesn't get started."

The owner's own words at 12:16:46: "There is nothing there yet, it just says no output yet, send
the engine an instruction to get started."

Codex does start. Every turn it runs exits 1, and nothing in the platform says so.

The pane, read live from production

GET /v1/instances/a1d3522f…/coding/sessions/csess_22d08431-591d-4936-bfd1-95c357667cd6/capture,
fetched 2026-08-12 23:14 UTC:

{"pane":"\n❯ [08:40:52] Run `git pull` in the repository at dev/aipa.\nReading additional input from stdin...\nNot inside a trusted directory and --skip-git-repo-check was not specified.\n[codex exited with code 1]\n\n❯ [08:40:56] Run the following shell command: cd dev/aipa && git pull\nReading additional input from stdin...\nNot inside a trusted directory and --skip-git-repo-check was not specified.\n[codex exited with code 1]\n\n❯ [08:41:00] Run the shell command: cd ~/dev/aipa && git pull\nReading additional input from stdin...\nNot inside a trusted directory and --skip-git-repo-check was not specified.\n[codex exited with code 1]",
 "alive":true,"ready":true,"runState":"idle","engineRuntime":"child-process","runnerConnected":true}

Three turns. Three exit-1s. alive: true, ready: true, runState: "idle".

Reproduced locally, on the same machine, with the shipped preset

codex-cli 0.147.0, RLs-MacBook-Air (the node this session ran on):

$ mkdir /tmp/probe && cd /tmp/probe        # NOT a git repo
$ codex exec --sandbox danger-full-access "say hi" </dev/null; echo "EXIT=$?"
Reading additional input from stdin...
Not inside a trusted directory and --skip-git-repo-check was not specified.
EXIT=1

$ git init -q .                            # the ONLY change
$ codex exec --sandbox danger-full-access "reply with the single word OK" </dev/null; echo "EXIT=$?"
…
codex
OK
EXIT=0

The failure is Codex's own gate: codex exec --help documents
--skip-git-repo-check Allow running Codex outside a Git repository. The shipped preset does not
carry it —

workers/api/src/lib/coding-engines.ts:269

{ id: "codex", label: "Codex", command: "codex exec --sandbox danger-full-access" },

and, grepped, the flag appears nowhere in the repository:

$ grep -rn "skip-git-repo-check" . | grep -v node_modules
(0 results)

(The directory in question is ~/dev/aipa, which has no .git — that half is #548. This issue is
about what the platform does when an engine turn fails, which would be the same for any non-zero
exit: a bad flag, an unauthenticated CLI, a wrong model name.)

The mechanism: a non-zero exit is prose, not a signal

packages/browser-runner/src/coding/headless.ts:528-543 (runOneShot's close handler):

proc.on("close", (code: number | null) => {
    clearTimeout(ceiling);
    if (code) this.push(`[${this.config.clientType} exited with code ${code}]`);
    if (this.proc !== proc) return;
    this.run = "idle";
    this.proc = null;
});

The exit code is pushed into the transcript as a line of text and then discarded. It sets no
field. The only structured failure flag a one-shot session has is spawnFailed
(headless.ts:214,511), and that is set solely from the error event — a binary that is not on
PATH. A binary that runs and refuses is indistinguishable from a binary that runs and succeeds:

headless.ts:294-297

get alive(): boolean {
    if (this.oneShot) return !this.stopped && !this.spawnFailed;

headless.ts:324

if (this.oneShot) return this.procAlive ? "thinking" : "idle";

So the exit sets runState to idle — which is the loop's word for ready for the next
instruction — and alive stays true. The snapshot the cloud receives
(packages/browser-runner/src/coding/runtime.ts:245-265) carries pane, alive, ready,
runState, authResolved, engineRuntime. There is no field for the outcome of the last turn.

What that costs the Pilot

runCodingLoop (workers/api/src/lib/coding-loop.ts:149-296) opens each step with two liveness
guards — snap.cancelled and !snap.alive — and neither fires. The brain is then handed the pane
as prose (decideCodingAction, :408-414) and left to work it out. In the production run it read
"Not inside a trusted directory" as a path problem and tried three path variants in eight
seconds (22:40:52 / 22:40:56 / 22:41:00), then called request_human. Nobody answered the handoff,
and 180 × 5s later (HANDOFF_WAIT_POLLS, workflows/coding-session.ts:54) the run closed
failed — stuck not resolved in time at 22:56:23. Three BYOK-Claude decisions and 15 minutes spent
on a signal the runner had in hand at 22:40:52.

Note this is not #522: the three instructions differ, so repetitionVerdict correctly did not
fire, and 73aa1c7 had been on main for twelve hours when this ran.

And what it costs the console

agents/coder/web/src/CodingTab.tsx renders the same pane. A fresh one-shot session legitimately
shows "no output yet" until a turn arrives (headless.ts:389-392 — start() is a no-op for a
one-shot engine, by design). The owner opened the Coding tab on a fresh Codex session at 12:16
and read that message as "Codex is broken". He was wrong about that session and right about the
engine, and nothing on the page could tell the two apart.

What to do, cheapest first

1. Carry the last turn's exit code in the snapshot. One field, one line in runOneShot's
close handler, one field in CodingSnapshot:

lastTurn?: { exitCode: number | null; at: number }

Everything below is a consumer of that one fact, and each is independently shippable.

2. Tell the Pilot, in the step log, not only in the pane. runCodingLoop already has the
channel: it feeds itself notes through actionLog for empty instructions (#504, :205-223) and
merge refusals (#314, :234-246), and the brain demonstrably reacts to them. Push
the engine exited with code 1 and produced no result — this is the engine refusing to run, not an answer to your instruction and the third path-variant retry does not happen.

3. Bound consecutive engine failures, exactly as MAX_EMPTY_INSTRUCTIONS = 3 bounds the
mirror case: N non-zero exits in a row → outcome: "failed" with the engine's own last stderr
line as the detail. failed here, not stuck: no human takeover fixes a CLI that refuses on
every invocation, and 15 minutes of unanswered handoff is the worst available ending.

4. Say it in the console. A repo row / session header that reads "the engine exited with code 1
on its last 3 turns" instead of a pane the owner has to parse.

5. The preset question — decide it, do not default it. Should codex ship with
--skip-git-repo-check? Arguments both ways, and it is genuinely the owner's call:

• For: Claude Code's preset has no equivalent gate, so the two engines behave differently for
  the same repo, which coding-engines.ts:238-246 explicitly calls a trap ("the trust level has
  to match across presets or the choice is a trap").
• Against: Codex's gate is a real safety property — it refuses to edit files in a folder with
  no version control and therefore no undo — and adding the flag would let an agent write into an
  unversioned directory. I would not add it. Fixing [bug] A run is admitted onto a folder the platform has already judged "not a git working tree", and starting it overwrites that verdict with ready — three git pull runs died on it #548 (refuse the run when the checkout is
  not a git work tree) removes the situation instead of suppressing the symptom, and preserves
  Codex's guarantee.

Alternatives considered and rejected

• Parse the pane for [… exited with code N]. The string is already there and a regex would
  work today. Rejected: it is a regex over an engine's prose, which is the class of guess [bug] A one-shot raw engine is judged idle by a 1.5s quiet timer and killed mid-turn — process exit is already the exact signal #391
  removed from runState in favour of the process's own exit. The runner has the exit code; it
  should carry it.
• Report alive: false after a non-zero exit. Rejected — it would resurrect the exact bug
  headless.ts:271-293 documents: a one-shot session has no process between turns, alive means
  "can take a turn", and a failing turn does not make the session unable to take another. The next
  turn might well succeed (different cwd, different instruction). Outcome and liveness are two
  facts; conflating them once already killed every delegated goal on codex/grok/gemini at
  iteration 0.

Acceptance criteria

1. CodingSnapshot carries the exit status of the last completed one-shot turn, and a runner test
   asserts it is 1 after a command that exits 1.
2. runCodingLoop appends a note to actionLog on a failed turn, and a unit test asserts the note
   reaches the next decide call's rendered step log.
3. N consecutive failed turns end the run as failed with the engine's own message, not as stuck
   → 15-minute handoff → failed.
4. Replaying this exact production pane through runCodingLoop produces at most one path-variant
   retry, not three.
5. The Coding tab distinguishes "no output yet (nothing has been sent)" from "the engine failed on
   its last turn".

Regression risk

• A legitimately non-zero exit that is still an answer. codex exec can exit non-zero after
  doing real work (a test suite it ran failed). Treating any non-zero exit as an engine failure
  would end useful runs. Mitigate with the "consecutive, and no output produced" pair — the same
  shape MAX_EMPTY_INSTRUCTIONS uses, and the reason it is documented as CONSECUTIVE.
• Old runners. The field is absent from any bundle older than this change; the cloud must treat
  undefined as "unknown", never as "failed" — the same rule verdictFromCheck applies to
  checked !== true (lib/coding-workdir.ts:78).
• The alive/runState semantics for one-shot engines are load-bearing ([bug] A one-shot raw engine is judged idle by a 1.5s quiet timer and killed mid-turn — process exit is already the exact signal #391, [enhancement] A raw engine forgets every previous turn — one-shot spawn is the design, and no preset, panel or doc says so #449). Any change
  there needs headless.test.ts's one-shot suite green.

Feedback row this closes

6a84f09a-821f-4ca2-9e8d-fbc8bae1d0fb (#514 capture, author agent).

[serge-ivo]

Shipped in three commits, each independently deployed and green on CI:

	commit	what
runner	056b69a	the turn's outcome becomes a field
Pilot	8bc3793	the loop reads it, tells the brain, bounds the streak
console	1baed0a	the tab says it in a sentence

The mechanism, as implemented. CodingSnapshot now carries
lastTurn: {verdict, exitCode, signal, at, detail}. Each engine mechanism reports what it can
honestly know: a raw one-shot turn IS a process, so its exit code is the verdict; Claude's
stream-json turn ends with a result event carrying is_error, so exitCode is null there rather
than invented. Leaving the structured path out would have given the field to three engines and
silently not to the flagship.

alive, ready and runState are unchanged, and a runner test asserts the production triple still
reads true/true/idle after a turn that exited 1 — per the issue's own rejected alternative.
Outcome and liveness stay two facts.

Two verdicts you did not ask for, both deliberate:

• killed — the 15-minute wedge ceiling and interrupt() terminate a process with a null code.
  That is evidence about this platform's timers, not the engine, so it counts as neither a success
  nor a failure. Three slow builds must not read as a broken CLI.
• the report is written AFTER the staleness guard — a turn pre-empted by its successor gets its
  close later than the successor's, so recording before the guard would file the loser's outcome
  as the session's latest. Tested.

Acceptance criteria

1. ✅ headless.test.ts spawns a fake that prints your exact refusal and exits 1: lastTurn is
   {verdict:"failed", exitCode:1} with the engine's sentence in detail — captured in pushRaw
   as it is written, never scraped back out of the pane.
2. ✅ coding-loop.test.ts asserts the note is in the actionLog the NEXT decide call renders.
   It reaches that call, not the one after: the read happens before deps.decide, so the brain sees
   it on the first decision after the failure.
3. ✅ Three consecutive failed turns end the run failed with the engine's own last line quoted —
   not stuck, for the reason you gave.
4. ⚠️ Partially, and deliberately. The replay ends after three failed turns (two retries), not
   one. A bound of two would end a run on one unlucky exit plus a single retry, and your own
   judgement paragraph names three consecutive as the threshold that is unhealthy "by any reading";
   MAX_EMPTY_INSTRUCTIONS is 3 for the same reason. The note is delivered after the FIRST failure,
   so a real brain can stop sooner — the bound is the backstop, not the mechanism. If you want two,
   it is one constant (MAX_ENGINE_FAILURES).
5. ✅ The Coding tab shows a banner above the pane naming the exit code, quoting the engine, and
   saying "that is the engine refusing to run, not an answer to your instruction". The empty-pane
   placeholder gains a fifth cause, ranked below "the engine is working" and "runner offline".

Old runners never read as failed. Absence is unknown — it neither counts toward the bound nor
resets it — and so is an unrecognised verdict, because the runner is a published npm package and may
be newer than the Worker. Tests cover both: a loop whose pane literally says
[codex exited with code 1] but whose runner sends no field runs to completion untouched, and the
console shows no banner for it.

The preset question (item 5): not added. --skip-git-repo-check stays off the Codex preset, for
the reason you gave — the gate is a real safety property, and #548 removed the situation instead of
suppressing the symptom.

What I did NOT do: the repo ROW label (resolveRepoState) gains no failed state. #548 already
makes that row say "unusable" for this exact production case, and adding a sixth RepoState would
touch three renderings for a fact the session view now states directly.

Verified in production: the live bundle at proagentstore.online/console carries the banner,
its id and the placeholder branch (fetched and grepped, 2026-08-13). CLI 0.4.51 is published to
npm with the runner change.

The one thing still needed from you: your machines are on 0.4.49, so nothing reports lastTurn
until you run npm i -g @proagentstore/cli and restart pags up. Until then every surface degrades
to exactly today's behaviour, which is what the "old runner" tests pin.

Guards proven by watching them fail (ADR 0002 G4): reverting the recording in runOneShot flips
four runner tests; reverting the loop's read to observeTurn(turns, undefined) puts the replay back
to stuck with an empty step log; disabling the placeholder branch puts "No output yet" back.

Full bar green on each commit: 8,403 unit tests, ten CI gates, and — for the console commit — 399
Playwright specs across chromium and WebKit, including the new 320px/390px phone checks.

[serge-ivo]

All five acceptance criteria are delivered and deployed; criterion 4's bound is 3 rather than 2, stated and reasoned above. Reopen if you want it at 2 — it is one constant.