TUI startup/render path is rough under mosh

What version of Codex CLI is running?

0.117.0

What subscription do you have?

pro

Which model were you using?

gpt-5.4 high

What platform is your computer?

Darwin 25.3.0 arm64 arm

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

Ghostty on macOS, connecting over mosh to a remote macOS host running tmux next-3.7.

What issue are you seeing?

When Codex runs over mosh, the TUI startup/render path still looks rough compared with plain SSH or other TUIs in the same transport path.

The symptoms in my setup were:

• visible startup control-sequence churn before the UI settles
• muted/incorrect secondary text in parts of the UI under mosh
• stale composer placeholder cells that made the initial render look worse than it should
• shaded panels looking slightly off compared with normal Codex rendering

My initial theory was too broad. I first thought this should be solved by an explicit mosh-only compatibility mode that broadly disabled a few terminal features. After actually fixing the path locally, that does not seem to be the right description of the fix.

What steps can reproduce the bug?

In my setup, this is reproducible with a MacBook client and a remote Mac host.

1. Connect to the remote host over mosh.
2. Run current main Codex in that session, optionally inside tmux.
3. Observe the startup paint and early redraw behavior.

In my environment, this roughness reproduced consistently with:

mosh <remote-host> -- codex

or:

mosh <remote-host> -- tmux new-session -A -s codex codex

What is the expected behavior?

Codex should render cleanly over mosh without transport-specific rendering artifacts or degraded text treatment.

Additional information

The local fix that actually worked was a short series, not a single env-gated compatibility mode:

• centralize mosh terminal capability handling in the TUI path instead of scattering ad hoc feature checks
• restore muted secondary text under mosh
• clear stale composer placeholder cells that were lingering in the first paint path
• always give shaded panels a semantic fallback background when the default palette cannot be queried reliably
• use COLORFGBG only to classify the fallback as dark or light, not as the exact panel RGB

That last point mattered more than I expected. Under mosh, the queried colors were good enough to tell dark from light, but not good enough to match Codex's normal neutral panel surfaces. Treating them as exact RGB values kept the UI looking slightly off even after the missing-background bug was fixed.

So the more accurate summary is: the remaining roughness was fixed by tightening capability handling and then cleaning up a few concrete rendering regressions, including fallback panel shading, not by introducing a broad CODEX_TUI_TRANSPORT=mosh mode.

Fork-local references:

• https://github.com/0xble/codex/pull/3
• https://github.com/0xble/codex/pull/4

Related issues in the same symptom family:

• #7829
• #11877
• #4415