codex-cli 0.92.0 panics on Broken pipe when stdout closes during --json streaming (macOS)

Summary

On macOS, codex-cli 0.92.0 can crash mid-run with a Rust panic:

failed printing to stdout: Broken pipe (os error 32)

We started seeing this only after upgrading to 0.92.0. It shows up most often in headless/detached runners where codex exec --json is piped (e.g. via tee) and the stdout consumer closes.

Environment

• codex-cli: 0.92.0
• macOS: 15.5 (24F74)
• Auth: API key (not ChatGPT login)

Observed error

From codex.stderr.log:

thread 'main' (...) panicked at library/std/src/io/stdio.rs:1165:9:
failed printing to stdout: Broken pipe (os error 32)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

How we trigger it

In our harness we were doing something like:

codex exec --json ... | tee events.jsonl >/dev/null

In headless/detached contexts, if the stdout consumer closes (runner exits, HUP, etc.), codex may panic with Broken pipe and terminate the run.

Minimal repro idea

This should not crash; it should exit gracefully if the consumer closes:

# Any prompt; keep it tiny to minimize cost.
codex exec --skip-git-repo-check --json "Print OK" | head -n 1 >/dev/null

(If head closes early, upstream should handle EPIPE without panicking.)

Workarounds

• Redirect stdout directly to a file instead of piping:

codex exec --json ... > events.jsonl 2> codex.stderr.log

• Pinning to codex-cli 0.91.0 avoids the issue for us in headless runs.

Requested behavior

Please handle EPIPE/BrokenPipe on stdout gracefully (no panic) when streaming --json.

Happy to provide more logs or try a debug build/backtrace if you point me at what to collect.