codex - 💡(How to fix) Fix Add `codex exec --quiet` to suppress the config summary banner for parent harnesses [3 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openai/codex#22047Fetched 2026-05-11 03:20:14
View on GitHub
Comments
3
Participants
2
Timeline
9
Reactions
0
Author
Timeline (top)
commented ×3labeled ×3closed ×1cross-referenced ×1

codex exec unconditionally writes a multi-line configuration banner to stderr before any model output:

OpenAI Codex v0.129.0
--------
workdir: /…
model: gpt-5.2-codex
provider: openai
approval: …
sandbox: workspace-write
reasoning effort: …
reasoning summaries: …
session id: 019dc5cf-…
--------
user
<echoed prompt>

When codex exec is being driven by a parent harness that renders its own status (e.g. an Ink/Ratatui front-end, a CI summary panel, or anything that wraps the JSON event stream alongside the human stream), every one of those lines has to be filtered out by literal string match. That is fragile — every cosmetic edit to the banner silently breaks downstream filters until somebody notices stale lines in their UI.

Root Cause

Add a global --quiet / -q flag to codex exec that short-circuits EventProcessorWithHumanOutput::print_config_summary. The flag is global so it also applies to codex exec resume and codex exec review. JSON mode (--json) is unaffected because it never emits the banner — it sends thread/started instead.

Code Example

OpenAI Codex v0.129.0
--------
workdir: /model: gpt-5.2-codex
provider: openai
approval:sandbox: workspace-write
reasoning effort:reasoning summaries:session id: 019dc5cf---------
user
<echoed prompt>

---

// from a parent harness that runs `codex exec` per turn
function cleanCodexOutput(value) {
  return stripAnsi(value)
    .split(/\r?\n/)
    .filter(line => {
      const t = line.trim();
      if (t.startsWith('OpenAI Codex v')) return false;
      if (t.startsWith('workdir:'))         return false;
      if (t.startsWith('model:'))           return false;
      if (t.startsWith('provider:'))        return false;
      if (t.startsWith('approval:'))        return false;
      if (t.startsWith('sandbox:'))         return false;
      if (t.startsWith('reasoning effort:')) return false;
      if (t.startsWith('reasoning summaries:')) return false;
      if (t.startsWith('session id:'))      return false;
      // ...
      return true;
    })
    .join('\n');
}
RAW_BUFFERClick to expand / collapse

Summary

codex exec unconditionally writes a multi-line configuration banner to stderr before any model output:

OpenAI Codex v0.129.0
--------
workdir: /…
model: gpt-5.2-codex
provider: openai
approval: …
sandbox: workspace-write
reasoning effort: …
reasoning summaries: …
session id: 019dc5cf-…
--------
user
<echoed prompt>

When codex exec is being driven by a parent harness that renders its own status (e.g. an Ink/Ratatui front-end, a CI summary panel, or anything that wraps the JSON event stream alongside the human stream), every one of those lines has to be filtered out by literal string match. That is fragile — every cosmetic edit to the banner silently breaks downstream filters until somebody notices stale lines in their UI.

Proposed solution

Add a global --quiet / -q flag to codex exec that short-circuits EventProcessorWithHumanOutput::print_config_summary. The flag is global so it also applies to codex exec resume and codex exec review. JSON mode (--json) is unaffected because it never emits the banner — it sends thread/started instead.

This is purely additive: behavior with no flag is unchanged.

Reference implementation

A working implementation with tests lives on the team-wcv fork:

Touches:

  • codex-rs/exec/src/cli.rs — adds the --quiet flag.
  • codex-rs/exec/src/lib.rs — plumbs through ExecRunArgs into the human event processor.
  • codex-rs/exec/src/event_processor_with_human_output.rs — adds the quiet: bool field and gates print_config_summary.
  • codex-rs/exec/src/cli_tests.rs — long/short/default + global = true parse coverage (including after resume).
  • codex-rs/exec/tests/suite/quiet.rs — end-to-end via the existing cli_responses_fixture.sse asserting the banner appears without the flag and is fully absent with --quiet / -q.

cargo test -p codex-exec passes (64 tests, 0 failures) on feat/exec-quiet-flag. just fix -p codex-exec reports no clippy issues.

Concrete example (downstream impact)

A real downstream filter that this flag would replace:

// from a parent harness that runs `codex exec` per turn
function cleanCodexOutput(value) {
  return stripAnsi(value)
    .split(/\r?\n/)
    .filter(line => {
      const t = line.trim();
      if (t.startsWith('OpenAI Codex v')) return false;
      if (t.startsWith('workdir:'))         return false;
      if (t.startsWith('model:'))           return false;
      if (t.startsWith('provider:'))        return false;
      if (t.startsWith('approval:'))        return false;
      if (t.startsWith('sandbox:'))         return false;
      if (t.startsWith('reasoning effort:')) return false;
      if (t.startsWith('reasoning summaries:')) return false;
      if (t.startsWith('session id:'))      return false;
      // ...
      return true;
    })
    .join('\n');
}

With --quiet, all of that goes away.

Why a flag, not config

A ~/.codex/config.toml knob would also work (e.g. [exec] quiet = true) but a CLI flag is more honest about the use case: parent harnesses spawn codex exec per turn and want to opt out per invocation, not per machine. Both could coexist, but the flag is the minimum useful surface.

Per docs/contributing.md

External contributions are by invitation only, so this is filed as an enhancement request with reference implementation attached. Happy to open the PR against this repo if the team finds the change useful and the approach acceptable.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING