[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
0Steps to Reproduce
- Configure a custom statusline in
~/.claude/settings.json:
{
"statusLine": {
"type": "command",
"command": "~/.claude/statusline.sh"
}
}- Open WezTerm
- Split the pane (horizontal or vertical split via WezTerm's native pane splitting, not tmux)
- Launch
claudein the newly created split pane - 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, buttput colssometimes 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 ofecho -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.
12 Comments
Found 1 possible duplicate issue:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
This is not a duplicate of #25430. While the visual symptom is similar (vertical character rendering), the root cause and behavior are fundamentally different:
| | #25430 (Windows) | This issue (macOS/WezTerm) |
|---|---|---|
| Platform | Windows 11 / PowerShell | macOS / WezTerm split pane |
| Trigger | Always — any custom statusline | Only when launched in a newly created split pane |
| Persistence | Permanent — resizing and restarting don't fix it | Transient — self-resolves after time (re-render / SIGWINCH) |
| Original pane | Also broken | Works correctly |
| Likely cause | Node.js pipe buffering on Windows | TUI renderer initializes with wrong terminal width (race condition with pane creation) |
#25430's author confirmed that resizing the terminal does not fix the issue, whereas in this case the issue resolves itself — indicating a different code path is responsible.
Also having this problem on MacOS using Ghostty
<img width="1220" height="217" alt="Image" src="https://github.com/user-attachments/assets/5f82d088-3a0a-4836-92b0-c9cfea43e567" />
I'm getting this on WSL using Windows Terminal - most often seen though when running inside a tmux.
I'm also seeing this in a Cursor terminal on macOS.
I'm seeing this on both MacOS and Linux, in multiple different terminals (e.g., wezterm, kitty). Something I noticed just now is that this problem does not occur when I change my terminal size to be 79 columns or less. If I start claude-code in a terminal window that is exactly 79 columns wide, I get a proper horizontally-oriented readable statusline. If I widen the screen by a single character, it switches to the vertical display. If I narrow it again, it fixes itself. As others have reported, it fixes itself after ~15 seconds or so, and works correctly at any width. I just thought it was notable that this doesn't appear to occur (for me) if the terminal window is _narrower_ than 80 columns. ymmv, of course.
Yes, can also confirm this only happens when the terminal is > 80 width
Reproduces on Ghostty 1.2.3 and Terminal.app, macOS (Darwin 24.6.0), Claude Code 2.1.47, with a custom status line script.
Same 80-column threshold — works correctly at 79 columns or fewer, breaks at 80+. The notification banner ("Claude Code has switched from npm to native installer...") takes the row, the status line gets squeezed into the remaining column and wraps character-by-character.
Note: this is not a race condition or timing issue. I can reproduce and fix it on demand by resizing the terminal window in real time — crossing 80 columns in either direction instantly switches between the broken and correct states. This is deterministic layout logic, not a startup timing problem.
Vertical wrapping (no room):
<img width="747" height="866" alt="Image" src="https://github.com/user-attachments/assets/7f3ff1cd-36cb-4385-bcb8-0e3449a81bd8" />
Vertical wrapping (some room):
<img width="1398" height="551" alt="Image" src="https://github.com/user-attachments/assets/2064d9ec-ed9b-4692-8b64-54b288aa1c54" />
No vertical wrapping (plenty of room):
<img width="1698" height="730" alt="Image" src="https://github.com/user-attachments/assets/946011c0-dc2c-4053-993e-0f52670c0210" />
Correct behavior, narrow terminal, stacked layout:
<img width="639" height="404" alt="Image" src="https://github.com/user-attachments/assets/20228f23-2f1e-4199-8560-a8d2938874f2" />
I can reproduce this on macOS (Darwin 25.3.0), Claude Code 2.1.62 using npm on multiple terminals. However, switching to a native install fixed this issue for me and side bonus, removed the annoying message too on startup.
related workaround for now - https://github.com/anthropics/claude-code/issues/23683
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.