Skip to content

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

@team-wcv

Description

@team-wcv

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestexecIssues related to the `codex exec` subcommand

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions