[BUG] tmux status bar redraw causes periodic unwanted line wraps in Claude Code TUI (both fullscreen and classic renderer)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Summary

When Claude Code runs inside a tmux session with the status bar (bottom bar) enabled, the input/output area periodically breaks into unexpected line wraps — even while completely
idle, with no keyboard input. This happens on a cadence that lines up with tmux's status bar redraw interval (status-interval 15). Turning the tmux status bar off (tmux set -g
status off) makes the problem disappear completely; turning it back on reproduces it again. This occurs with both the fullscreen renderer and the classic renderer (/tui default),
so it is not renderer-specific.

Reproduction steps

1. Start tmux with a status bar enabled (default config, status on, status-interval 15).
2. Inside the tmux pane, run claude.
3. Do nothing — leave the session completely idle (no typing, no Claude response in progress).
4. Watch the input box / screen: it periodically re-wraps / breaks lines on its own. We noticed this correlating with the minute digit changing in a %H:%M clock in the tmux status

bar (roughly once per minute observed, against a 15s status-interval).

1. Run tmux set -g status off in the same session. The periodic line-wrap glitch stops immediately and does not recur even after several minutes of idling.
2. Run tmux set -g status on again. The glitch returns.

Tested and reproduced with both:

• Fullscreen renderer (default / /tui fullscreen)
• Classic renderer (/tui default)

Expected behavior

Claude Code's TUI should not re-wrap or corrupt the displayed input/output when tmux redraws its own status bar. The status bar redraw is a separate UI region and shouldn't affect
the pane's rendered content.

Actual behavior

The pane content (including the input box) periodically breaks/re-wraps lines with no user action, in a way that makes typing difficult when it happens frequently. It stops entirely
when the tmux status bar is disabled.

Environment

• Claude Code version: 2.1.252
• tmux version: 3.6
• Terminal emulator: TeraTerm (connecting via SSH)
• OS (remote host running tmux/claude): Linux uec-cefore-ws 7.0.0-30-generic #30-Ubuntu SMP PREEMPT_DYNAMIC Fri Jul 31 18:22:54 UTC 2026 x86_64 GNU/Linux
• Connection: SSH via TeraTerm → tmux → claude
• tmux status-interval: 15
• Locale on remote host: ja_JP.UTF-8 (LANG, LC_CTYPE, etc. all ja_JP.UTF-8; LC_ALL unset)

Additional notes

• Confirmed unrelated to CJK/ambiguous-width character rendering per se — the glitch occurs with zero keystrokes typed, purely from idling with the status bar on. (Separately, we did

also observe CJK/box-drawing character clipping consistent with #23534, resolved locally by setting TeraTerm's Unicode "Ambiguous Character Width" from 2 to 1 — but that fix did not
affect this issue.)

• Confirmed unrelated to tmux mouse and focus-events settings — both were enabled (set -g mouse on, set -g focus-events on) and the issue persisted.
• May be related to #51497 (fullscreen renderer not accounting for tmux status bar height) and #1495 (TUI rendering glitches suspected to be tied to tmux terminal-size tracking), but

this report reproduces cleanly and consistently by toggling status off/on, and occurs in the classic renderer too, which suggests the root cause is broader than the
fullscreen-specific row-count bug in #51497.

Workaround

Disabling the tmux status bar (tmux set -g status off) for the duration of the Claude Code session avoids the issue entirely.

What Should Happen?

Claude Code's TUI should not re-wrap or corrupt the displayed input/output when tmux redraws its own status bar. The status bar redraw is a separate UI region and shouldn't affect
the pane's rendered content.

Error Messages/Logs

N/A — this is a visual rendering glitch (unwanted line wraps), not a crash or error. No error messages were printed to the terminal or logs.

Steps to Reproduce

Reproduction steps

1. Start tmux with a status bar enabled (default config, status on, status-interval 15).
2. Inside the tmux pane, run claude.
3. Do nothing — leave the session completely idle (no typing, no Claude response in progress).
4. Watch the input box / screen: it periodically re-wraps / breaks lines on its own. We noticed this correlating with the minute digit changing in a %H:%M clock in the tmux status

bar (roughly once per minute observed, against a 15s status-interval).

1. Run tmux set -g status off in the same session. The periodic line-wrap glitch stops immediately and does not recur even after several minutes of idling.
2. Run tmux set -g status on again. The glitch returns.

Tested and reproduced with both:

• Fullscreen renderer (default / /tui fullscreen)
• Classic renderer (/tui default)

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

Unknown — have not tested on earlier Claude Code versions.

Claude Code Version

2.1.252

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

_No response_