Bug: exec aggregated output can exceed EXEC_OUTPUT_MAX_BYTES on async exec path
What Version Of Codex Is Running?
codex-cli 0.89.0
What Subscription Do You Have?
Plus
Which Model Were You Using?
gpt-5.2-codex
What Platform Is Your Computer?
Darwin 25.3.0 arm64 arm
What Terminal Emulator And Version Are You Using (If Applicable)?
Terminal.app 466 (TERM_PROGRAM=Apple_Terminal), shell: /bin/zsh, TERM=xterm-256color
What Issue Are You Seeing?
Aggregated exec output can exceed the configured cap (EXEC_OUTPUT_MAX_BYTES) on the async exec path. In codex-rs/core/src/exec.rs, stderr is appended with a max of EXEC_OUTPUT_MAX_BYTES * 2, so when both stdout and stderr are large, aggregated_output can grow beyond the intended max. This is inconsistent with the Windows sandbox path (which caps at EXEC_OUTPUT_MAX_BYTES).
What Steps Can Reproduce The Bug?
- Run an exec that emits large stdout and stderr (e.g., ~1MiB each).
- Inspect ExecToolCallOutput.aggregated_output (via debugger or internal logging).
- Observe aggregated_output length > EXEC_OUTPUT_MAX_BYTES.
Example generator:
python - <<'PY'
import sys
sys.stdout.write("x" (1024 1024))
sys.stderr.write("y" (1024 1024))
PY
What Is The Expected Behavior?
aggregated_output is consistently capped at EXEC_OUTPUT_MAX_BYTES across all exec paths.
Additional Information
Inconsistent behavior: Windows sandbox path already caps aggregated output to EXEC_OUTPUT_MAX_BYTES, while the async exec path can exceed that cap.
3 Comments
Note: I updated the repro to clarify that aggregated_output exceeds the cap when both stdout and stderr are large (e.g., ~1 MiB each). The issue body now reflects that.
It sounds like your use case is pretty atypical. If your need outputs that large, you may want to ask codex to write the response to a file rather than using stderr and stdout.
Thanks for the guidance @etraut-openai . I agree that for large outputs it’s better to write to a file. This report is mainly about enforcing the existing EXEC_OUTPUT_MAX_BYTES cap consistently.
For context, I run a local orchestrator that parses exec tool output for auditing/telemetry. Consistent capping makes the downstream processing safer and more predictable. I have already applied the suggested fix to my fork, let me know if I should close the issue/pr.