[Bug] Custom statusline renders vertically when launched in WezTerm split pane (macOS)

Description

When Claude Code is launched inside a WezTerm split pane (not the original/first pane), the custom statusLine command output renders each character on its own line (vertically) instead of horizontally. The issue resolves itself after some time (typically after the first API response triggers a re-render), but the initial display is severely broken.

This appears to be caused by Claude Code's TUI renderer initializing with incorrect terminal dimensions (possibly width=0 or 1) before WezTerm has fully reported the pane size.

Symptom

Left pane (original, working correctly): statusline shows .config | 0% | $0.00
Right panes (created via split): each character of the statusline renders on its own line:

.
c
o
n
f
i
g

|

0
%

|

$
0
.
0
0

Steps to Reproduce

1. Configure a custom statusline in ~/.claude/settings.json:

{
  "statusLine": {
    "type": "command",
    "command": "~/.claude/statusline.sh"
  }
}

1. Open WezTerm
2. Split the pane (horizontal or vertical split via WezTerm's native pane splitting, not tmux)
3. Launch claude in the newly created split pane
4. The statusline renders vertically in the new pane

Expected Behavior

The statusline should render horizontally in a single line, regardless of whether Claude Code is launched in an original pane or a split pane.

Actual Behavior

• The statusline output is rendered with each character on its own line (as if terminal width is 1)
• The rest of the TUI (welcome banner, prompt) renders correctly
• The issue self-resolves after time (likely when a SIGWINCH or re-render is triggered)
• The original (unsplit) pane always renders correctly

Workarounds Attempted

From the statusline script side, we tried:

• Guard on tput cols < 30: Partially helps, but tput cols sometimes returns the correct value even when the TUI renderer has the wrong width
• Guard on total_duration_ms == 0: Skip rendering before first API response — helps reduce occurrences but doesn't eliminate the issue
• printf '%b' instead of echo -e: As recommended in docs — no effect on this issue
• Responsive output (shorter output for narrow terminals): Doesn't help because the TUI renderer itself is using width=1

These workarounds confirm the issue is in Claude Code's TUI renderer, not in the statusline script output.

Environment

• Claude Code: 2.1.41
• OS: macOS (Darwin 25.0.0)
• Terminal: WezTerm (GPU-accelerated, native pane splitting)
• Shell: zsh
• TERM: xterm-256color
• Not using tmux for the pane split — this is WezTerm's native split pane feature

Related Issues

• #25430 — Same vertical rendering symptom but on Windows (attributed to Node.js pipe buffering)
• #24866 — Update notification wraps vertically on narrow terminals (same wrapping behavior, different trigger)
• #24514 — ANSI escape codes counted toward line length (contributes to wrapping but different root cause)

Analysis

The root cause appears to be that Claude Code's TUI renderer (Ink/React) queries terminal dimensions at startup and gets an incorrect value (likely width=0 or 1) when the WezTerm pane has just been created. The renderer then lays out the statusline area with this incorrect width. Although the terminal quickly reports the correct dimensions (via SIGWINCH), the statusline may not re-render until the next update cycle.

The default built-in statusline does not exhibit this issue — only custom statusLine command output is affected, suggesting the custom statusline rendering path has a different (possibly deferred) width detection mechanism.