Unified exec should suppress editor and progress output by default

Open 💬 5 comments Opened May 21, 2026 by dfredriksen

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What issue are you seeing?

When Codex runs shell commands through unified exec in repositories or build workflows, some common tools can still enter interactive or ANSI/progress output modes despite the existing TERM=dumb, NO_COLOR=1, and pager defaults. This can leak raw control sequences into the Codex transcript or leave commands waiting on an editor.

This is related to the previously closed report #6850 and the merged partial fix #7286. The current unified exec defaults already set PAGER=cat, GIT_PAGER=cat, and GH_PAGER=cat, but they do not currently cover editor-driven Git flows (git merge, git rebase, commit/edit prompts) or other common progress/color environment conventions.

I prepared a small branch from current main that extends the default unified exec environment and updates the existing unit test:

https://github.com/dfredriksen/codex/tree/fix/unified-exec-plain-git-env

Given the contribution policy for external PRs, I am opening this issue first rather than marking an unsolicited PR ready for review.

What steps can reproduce the bug?

Examples that can produce noisy transcript output or editor waits from a Codex shell command:

In a git repository, run a command path that invokes an editor, such as a merge/rebase/commit flow that needs an edit message.
Run tools that use forced color/progress output unless explicitly disabled, such as Docker BuildKit progress output.
Observe raw cursor-control/progress escape sequences in command output or a process waiting for an interactive editor.

What is the expected behavior?

Codex tool-command transcripts should be line-oriented and reviewable by default. Non-interactive Codex command execution should avoid launching editors and should prefer plain progress/color output unless the user explicitly asks for an interactive TTY-like workflow.

Additional information

A proposed focused change is to add these defaults to UNIFIED_EXEC_ENV:

CLICOLOR=0
CLICOLOR_FORCE=0
EDITOR=true
VISUAL=true
GIT_EDITOR=true
GIT_SEQUENCE_EDITOR=true
GIT_MERGE_AUTOEDIT=no
DOCKER_BUILDKIT_PROGRESS=plain

Local branch commit: 15ae078b50.

Local verification attempted:

cargo fmt --check completed successfully, though stable rustfmt prints warnings that the repo's imports_granularity=Item option is nightly-only.
cargo test -p codex-core unified_exec_env started compiling but failed locally because the machine ran out of disk space while writing Rust build artifacts (os error 112).

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#22604

Powered by Codex Action

dfredriksen · 3 months ago

Update: I got the repo formatter helper running locally after installing the missing helper tools.

Verification now completed:

just fmt from codex-rs passes end to end.
Branch remains clean after formatting: https://github.com/dfredriksen/codex/tree/fix/unified-exec-plain-git-env

Still not completed locally:

cargo test -p codex-core unified_exec_env could not finish on this machine because the first Rust build exhausted local disk while compiling codex-core (os error 112).

I am holding off on opening a PR because docs/contributing.md says external PRs are invitation-only. If this approach aligns with the maintainers' intended fix, I can open the prepared branch as a PR.

dfredriksen · 3 months ago

Follow-up after reviewing the auto-detected related issue #22604:

#22604 is related but narrower: it covers jj paging because jj has a tool-specific JJ_PAGER override.
This branch now also sets JJ_PAGER=cat in the same unified exec defaults, so the prepared patch covers that open pager gap as well.
Updated branch commit: https://github.com/dfredriksen/codex/commit/ab3542ba4ee7dec89ac92931acbc54c2c5cf1d0f

Verification after the update:

just fmt from codex-rs passes.
cargo test -p codex-core unified_exec_env --lib was attempted again, but this Windows machine still runs out of local disk while compiling codex-core dependencies / first-party crates (os error 112).

dfredriksen · 3 months ago

Verification update after freeing local disk space:

cargo test -p codex-core unified_exec_env --lib now passes locally.
Result: 2 passed, 0 failed, 1732 filtered out.
just fmt was already passing after the branch update.

So the prepared branch now has both formatter and targeted Rust test coverage passing locally.

dfredriksen · 3 months ago

Follow-up after testing the TUI path more directly on Windows:

The earlier unified-exec environment patch does not fully fix this issue. The failure is refresh-specific: the first TUI render can look correct, but a later refresh after startup/MCP activity can print raw ANSI escapes in a Git working tree.

The working local fix is now on the branch here:

https://github.com/dfredriksen/codex/commit/1b6716bd6a4b2b6e2400756f9847892094ad48c2

What changed:

Enable ENABLE_PROCESSED_OUTPUT | ENABLE_VIRTUAL_TERMINAL_PROCESSING during TUI mode setup on Windows.
Re-enable that console mode before each Windows TUI frame, because the mode appears able to change after startup while child processes initialize.
Keep SynchronizedUpdate on non-Windows, but avoid wrapping Windows redraws with synchronized updates.

Verification:

cargo fmt -- --config imports_granularity=Item passes locally, with the existing stable-rust warning about imports_granularity requiring nightly.
cargo check -p codex-tui passed locally.
cargo build --locked --bin codex passed locally.
A patched codex-fix binary built from this commit was tested in a fresh PowerShell session inside C:\Users\Dan\Desktop\Projects\igh-planning; the refresh issue no longer reproduced there.