Add `codex exec --quiet` to suppress the config summary banner for parent harnesses

Resolved 💬 3 comments Opened May 10, 2026 by team-wcv Closed May 10, 2026

💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

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.

View original on GitHub ↗

3 Comments

etraut-openai contributor · 3 months ago

If you are wrapping codex exec with another tool that processes its output, we recommend using --json. The output of non-json mode is intended for human consumption, not tool consumption.

team-wcv · 3 months ago

Thanks for taking a look! Quick clarification on the use case in case it changes the calculus — and totally fine if it doesn't.

The wrapper here isn't parsing the output; it passes the human-readable stream straight through to a real human at a terminal. It prints its own banner first (cluster topology, peer health, etc.) and the duplicated OpenAI Codex v… / workdir / model / provider / … block is the only thing we want suppressed. Switching to --json would mean re-implementing what EventProcessorWithHumanOutput already does well — turn streaming, tool-call rendering, reasoning deltas, ANSI styling — just to render it back to a human, so the trade doesn't really come out positive.

The proposed flag is opt-in (--quiet defaults to false), so direct users see no change and the banner stays the canonical default.

Totally happy to keep this closed if a --quiet knob on the human renderer isn't somewhere you want to grow — we'll keep filtering banner lines downstream. It's just brittle across cosmetic edits, which is what prompted the issue in the first place. Either way, thanks for the project!