codex exec non interactive mode prints duplicate output

Resolved 💬 7 comments Opened Feb 23, 2026 by pankajbisht10 Closed Jun 12, 2026
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.98.0

What subscription do you have?

Oracle Code Assist

Which model were you using?

gpt-5-codex

What platform is your computer?

Oracle Linux OL 8

What terminal emulator and version are you using (if applicable)?

Codex CLI

What issue are you seeing?

bash-4.4$ codex exec "Print 5 cities in numbered list"
OpenAI Codex v0.98.0 (research preview)
--------
workdir: /home/XXXX
model: gpt-5-codex
provider: xxxxxxxx
approval: never
sandbox: workspace-write [workdir, /tmp, $TMPDIR]
reasoning effort: none
reasoning summaries: auto
session id: xxxxxxxxxxxx
--------
user
Print 5 cities in numbered list
codex

  1. New York City
  2. Los Angeles
  3. Chicago
  4. Houston
  5. Phoenix

tokens used
1,085

  1. New York City
  2. Los Angeles
  3. Chicago
  4. Houston
  5. Phoenix

What steps can reproduce the bug?

codex exec <any task of your choice to print>

What is the expected behavior?

It should print the message once

Additional information

_No response_

View original on GitHub ↗

7 Comments

pdonizete · 4 months ago

Hi! I can take this one. I’ll reproduce the duplicate output in and propose a focused fix with tests.

pdonizete · 4 months ago

Opened a fix PR: https://github.com/openai/codex/pull/12828

It suppresses duplicate final output in interactive terminals while preserving stdout output for piped/CI usage.

pdonizete · 4 months ago

Thanks for the policy clarification — understood on invite-only code contributions.\n\nFor maintainers’ convenience, here is the technical rationale for the fix I tested for #12566:\n\n- Root cause: in , the final assistant message is emitted once during handling (stderr), and then emitted again in (stdout), which causes visible duplication in interactive terminal runs.\n- Proposed behavior: keep stdout emission only for non-interactive contexts (pipes/CI), where machine-readable final output is expected.\n- Implementation detail: gate the final stdout print on using .\n- Safety:\n - Interactive TTY: no duplicate human-visible output.\n - Piped/non-interactive mode: final stdout output preserved for scripts and CI workflows.\n- Tests added: helper-level tests for to lock behavior.\n\nPatch reference (fork branch/commit):\n- commit: https://github.com/pdonizete/codex/commit/912fc3966\n- branch compare: https://github.com/pdonizete/codex/compare/main...pdonizete:fix/12566-exec-duplicate-output\n\nIf this aligns with project direction, I’d be happy to provide the same change via an invited PR route.

pdonizete · 4 months ago

Thanks for the policy clarification — understood on invite-only code contributions.

For maintainers’ convenience, here is the technical rationale for the fix I tested for #12566:

  • Root cause: in codex-rs/exec/src/event_processor_with_human_output.rs, the final assistant message is emitted once during EventMsg::AgentMessage handling (stderr), and then emitted again in print_final_output() (stdout), which causes visible duplication in interactive terminal runs.
  • Proposed behavior: keep stdout emission only for non-interactive contexts (pipes/CI), where machine-readable final output is expected.
  • Implementation detail: gate the final stdout print on !stdout.is_terminal() using std::io::IsTerminal.
  • Safety:
  • Interactive TTY: no duplicate human-visible output.
  • Piped/non-interactive mode: final stdout output preserved for scripts and CI workflows.
  • Tests added: helper-level tests for (message present/absent) x (tty/non-tty) to lock behavior.

Patch reference (fork branch/commit):

If this aligns with project direction, I’d be happy to provide the same change via an invited PR route.

etraut-openai contributor · 4 months ago

Thanks for the bug report. And @pdonizete, thanks for the analysis — it was spot on.

This will be fixed in the next release.

pdonizete · 4 months ago

Thanks — I appreciate it. I’m glad my analysis was helpful and that the fix is now in.
I’ll verify on my side once the next release is out.

ax-openai · 1 month ago

Closing as resolved in current releases.