Codex 0.130.0 still loses background/pill colors inside tmux 3.6a

Hey guys, is there any intent on merging this in?

Also hitting this, with a much more thoroughly isolated repro than I initially expected — sharing the full elimination trail in case it narrows down the root cause.

Environment: macOS, Codex CLI 0.142.5, installed via Nix profile, Ghostty (outer terminal), tmux 3.6a. TERM=xterm-256color, COLORTERM=truecolor, both confirmed correctly set and inherited (checked via bare env, no sudo involved).

Symptom: Inside tmux, Codex loses semantic/theme coloring — bold formatting still works, but hex theme colors collapse toward black/near-black or a flat gray instead of rendering as distinct hues. Most noticeable on diff output specifically, which shows no color at all inside tmux where it's fully colored outside tmux, identical command, identical flags, identical binary.

Ruled out, in order tested:

• Stale $TERM from an old pane/shell — confirmed xterm-256color in the failing session directly.
• Any wrapper/secrets-injection tooling (I normally run Codex through a script that pipes through op run for MCP secrets) — bypassed entirely, invoked the resolved binary directly with the same flags; bug still reproduces. So it's not injection tooling interfering with stdio/env.
• sudo environment stripping — not applicable to this invocation, but separately confirmed irrelevant.
• Generic terminal color-capability detection — confirmed fully healthy in the exact same tmux pane: raw ANSI truecolor escapes (\e[38;2;r;g;bm) render correctly, tput bold/tput setaf/tput colors all correct (256), ls/eza --color=auto and grep --color=auto both auto-detect and colorize correctly (unpiped), and Vim's syntax highlighting (e.g. TOML) renders fully colored. So this is not a tmux/terminfo/general-auto-detection problem — every other tool in the same pane, same session, gets this right.
• Manual override env vars — tried FORCE_COLOR=3, CLICOLOR_FORCE=1, and forcing TERM_PROGRAM=ghostty (since $TERM_PROGRAM reports tmux inside a tmux session) — none changed the behavior.
• Earlier suspected OSC 11 background-query failure through tmux — tested directly (printf '\e]11;?\e\\') and tmux correctly relays an accurate background-color response, so it's not simply a dead/garbled OSC 11 round-trip either. (Possibly still a timing/race on that query specifically — untested — but the response mechanism itself works.)

Net effect: something in Codex's own theme/color-rendering path is making a different (and incorrect) capability decision when it detects it's running inside tmux, despite every generic and terminfo-based capability check in the same pane being correct. Given TERM_PROGRAM=tmux is reliably present and distinguishable in this context, that seems like the most likely signal Codex is keying off internally, but I don't have visibility into the actual detection code to confirm.

Happy to run further diagnostics (timing captures, testing specific tui.theme config combinations, etc.) if useful.

Confirmed: this is still reproducible with Codex CLI 0.144.4.

Environment

• macOS 26.5.2, arm64
• Codex CLI 0.144.4 (@openai/codex via npm)
• tmux 3.6a
• Codex running inside tmux over SSH
• Actual Codex process environment:
• TERM=tmux-256color
• COLORTERM=truecolor
• TERM_PROGRAM=tmux
• NO_COLOR is not set

Symptom

Both the composer/input background and completed user-message background pill are missing inside tmux. Other colors, including the truecolor status line, render correctly.

I captured the live pane with escape attributes preserved. User messages had foreground color but no background SGR, and the composer was explicitly rendered with the terminal default background (49). This is not a generic no-color or 256-color failure.

Negative controls

• One-off tui.alternate_screen="always": no change
• TERM=tmux-256color and COLORTERM=truecolor confirmed in the actual native Codex process
• Codex 0.143.0: same behavior
• Current config has no semantic/composer background override; tui.theme only changes syntax highlighting

Code-path match

The current 0.144.4 source still has the same fallback:

pub fn user_message_style_for(terminal_bg: Option<(u8, u8, u8)>) -> Style {
    match terminal_bg {
        Some(bg) => Style::default().bg(user_message_bg(bg)),
        None => Style::default(),
    }
}

ChatComposer and user-message history cells both use user_message_style(), which explains why both backgrounds disappear together. The startup probe still has a fixed 100 ms deadline for the OSC 10/11 color query. The observed result is therefore consistent with default_bg() == None, and also with the SSH timing report in #23489.

This remains a practical problem for tmux-based remote workflows. A configurable fallback background, an asynchronous/retry probe, or a non-empty fallback for None would prevent the composer and user-message distinction from disappearing when OSC 10/11 is unavailable or late.

FWIW It would be great to have a configuration option to completely disable background colors for the user prompt.
Right now, I have to rely on a custom CLI wrapper that strips OSC10/11 TTY responses just to bypass it, but native support would be much better.