[BUG] TUI renders blank inside tmux on startup (iTerm2/macOS, external display only); UI appears only while window is being resize-dragged

[BUG] TUI renders blank inside tmux on startup (iTerm2/macOS, external display only); UI appears only while window is being resize-dragged, vanishes on mouse release

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet (closest match is #52731 — blank viewport fixed by /tui no-op redraw — but that requires a long response/table mid-session; this occurs immediately at startup, before the trust prompt is ever visible)
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

Environment

• Claude Code version: 2.1.205 (native install; claude upgrade reports up to date)
• OS: macOS 26.5.2 (21624.2.5.11.8)
• Terminal: iTerm2 Build 3.6.11
• tmux: tmux 3.7a
• $TERM inside tmux: tmux-256color
• Shell: zsh 5.9 (arm64-apple-darwin25.0)
• External display: Dell P3225QE
• Built-in display: MacBook Pro 14" M5
• Working comparison path: remote tmux + Claude Code over mosh <!-- fill in: mosh version, remote OS --> in the same iTerm2 window/display — renders fine
• Pane geometry at time of bug: 209x51, client 209x52 (single full-window pane, no splits) — but also reproduces at 80x24, see below

What's wrong?

When claude is started inside a tmux session, the TUI does not render. The screen stays almost entirely blank — no welcome banner, no "do you trust this directory" prompt, no input prompt. The only visible content is a small fragment of the welcome footer near the bottom of the window (the text for agents).

Claude Code is not hung: it is running and accepting input. Typing slash commands blind works — e.g. /exit quits normally.

Key observation: if I grab the corner of the iTerm2 window and drag to resize, the full Claude Code UI flickers into view and stays visible for as long as I keep dragging (i.e. while continuous resize/redraw events are being delivered). The moment I release the mouse button, the UI disappears again, back to the blank screen with the footer fragment.

This suggests the content/emission path is fine and forced full redraws render correctly, but the incremental/steady-state render path immediately blanks or fails to composite the viewport — similar in character to #52731, but triggered at startup under tmux rather than mid-session.

Second key observation: the bug only occurs when the iTerm2 window is on an external display. With the same machine, same Claude Code version, and same tmux session type, moving to the built-in laptop display (external display unplugged, lid open) renders perfectly. On the external display it fails every time, independent of window size (fails at both 209x51 and 80x24) and independent of iTerm2's GPU rendering setting (fails with GPU rendering both on and off).

Third key observation: a remote tmux + Claude Code session accessed via mosh, in the same iTerm2 window at the same size on the same external display, renders fine. Since mosh runs its own terminal emulation server-side and synthesizes output rather than passing the byte stream through, the remote tmux negotiates capabilities against mosh instead of iTerm2, ending up with a much smaller feature set (see Additional context).

Steps to reproduce

1. On macOS with the iTerm2 window on an external display, start a tmux session with no user config to rule out configuration:

``
tmux -L clean -f /dev/null new -s clean
``

1. Run claude inside the session.
2. Observe: blank screen except a fragment of the welcome footer (for agents) at the bottom. No trust prompt, no input prompt.
3. Drag-resize the iTerm2 window: the full UI renders while dragging, disappears on mouse release.
4. Type /exit blind: Claude Code exits normally, confirming it was alive and processing input.
5. Unplug the external display and repeat steps 1–2 on the built-in laptop display: everything renders normally.

Expected behavior

The welcome banner, trust prompt, and input prompt render normally on startup inside tmux, as they do when running claude directly in iTerm2 (which works fine on the same machine, same version).

What I've ruled out

• tmux user config: reproduces with tmux -f /dev/null on a freshly started dedicated server (-L clean), and after tmux kill-server on my normal server.
• Stale/hung process: slash commands typed blind are processed (/exit works).
• Pane/client size mismatch: tmux display -p '#{pane_width}x#{pane_height} client=#{client_width}x#{client_height}' reports 209x51 client=209x52 — sane values.
• TERM: tmux-256color inside the session.
• Unrelated terminal-title config: I initially suspected set -g set-titles on, but toggling it off has no effect, and the bug reproduces with no tmux config at all.
• Window/pane size: reproduces at both 209x51 and 80x24 on the external display.
• iTerm2 GPU rendering: reproduces with GPU rendering enabled and disabled.
• Synchronized output (DEC 2026): reproduces on a fresh tmux server started with set -as terminal-overrides ',xterm*:Sync@'. Byte-level capture via script(1) confirms the override works: grep -aFc $'\e[?2026h' finds 8 occurrences in a default-config session and 0 in the override session, yet the bug reproduces in both. (Note: sync still appears in #{client_termfeatures} under the override — that variable reports detected features, not effective capabilities.)
• Other full-screen TUIs (<!-- confirm: e.g. htop, vim -->) render normally in the same pane.

Workarounds tried

• Moving the iTerm2 window to the built-in laptop display: works (but is a workaround, not a fix).
• /tui fullscreen typed blind in the broken state: <!-- fill in result before posting: fixed rendering / no effect -->
• Ctrl+L: <!-- fill in result -->
• Dragging the iTerm2 window from the external display to the built-in display without restarting Claude Code: <!-- fill in if tested: does the UI appear? -->

Additional context

Running claude directly in iTerm2 (no tmux) renders perfectly on the same machine and version, including on the external display. Running tmux + claude on a remote server via mosh, in the same iTerm2 window at the same size on the same external display, also renders perfectly. So the failing combination is specifically: local tmux + iTerm2 + external display.

Suspecting a terminal-capability difference, I compared tmux display -p '#{client_termfeatures}' between the two paths:

• Failing local session (iTerm2 direct): 256,bpaste,ccolour,clipboard,hyperlinks,cstyle,extkeys,focus,margins,mouse,osc7,progressbar,RGB,sixel,strikethrough,sync,title,usstyle
• Working remote session (via mosh): bpaste,ccolour,clipboard,cstyle,focus,title

Synchronized output (DEC 2026) is ruled out: with a fresh tmux server started under set -as terminal-overrides ',xterm*:Sync@', a script(1) byte capture confirms zero \e[?2026h sequences are emitted (vs 8 in a default-config control run), and the bug still reproduces identically. The remaining feature-set difference (256, extkeys, hyperlinks, margins, mouse, osc7, progressbar, RGB, sixel, strikethrough, usstyle) has not been bisected. It's also possible the relevant difference isn't a tmux feature at all but something Claude Code itself does differently when it detects a more capable terminal.

The display-dependence remains unexplained: identical software path, identical window size, fails on the external display and works on the built-in one.

Happy to provide claude doctor output, debug logs, or a screen recording of the resize-drag behavior on request.