[BUG] TUI renders garbled inside tmux since 2.1.200 (last-good 2.1.199) — only repaints on forced redraw

Summary

Since v2.1.200, the Claude Code TUI renders garbled inside tmux — text is
corrupted/overwritten and does not repaint on its own. It only redraws correctly
when a forced full redraw happens (switching tmux panes, or resizing). This is a
clean regression: v2.1.199 renders correctly; v2.1.200 and v2.1.201 do not, same
terminal, same tmux, same config.

Correction (updated): this report originally pinned the regression to 2.1.201 with 2.1.200 as last-good. Further bisection proved that wrong — 2.1.200 is also garbled. The real last-good build is 2.1.199. The regression landed in 2.1.200 and persists in 2.1.201. Title/table/workaround below have been corrected accordingly.

Regression bisection

| Version | Result |
|---|---|
| 2.1.199 | ✅ renders correctly in tmux |
| 2.1.200 | ❌ garbled until a forced redraw (pane switch / resize) |
| 2.1.201 | ❌ garbled (same behavior; inherited from 2.1.200) |

Nothing else changed across these builds — tmux, terminfo, and the terminal emulator
were identical. Rolling the native-install symlink back to 2.1.199 restores
correct rendering; 2.1.200 reproduces the corruption, confirming the regression
first landed in the 2.1.200 build.

Environment

• Claude Code 2.1.200 / 2.1.201 (native installer, macOS arm64) — both regressed;

2.1.199 OK

• tmux 3.7a (unchanged across good/bad builds)
• iTerm2 3.6.11
• TERM=tmux-256color, COLORTERM=truecolor, tmux client reports RGB + sync

(synchronized-output / mode 2026) features

• macOS (Darwin 25.5.0)

Steps to reproduce

1. Run Claude Code v2.1.200 (or 2.1.201) inside a tmux pane (iTerm2 outer, tmux-256color).
2. Interact so the TUI repaints (type, let output stream, scroll).
3. Text becomes garbled / overwrites itself and stays that way.
4. Switch to another tmux pane and back → the pane redraws correctly, then degrades

again on the next update.

Likely area

The "stays garbled until a forced full redraw" behavior is the classic signature of a
synchronized-update (\e[?2026h / \e[?2026l) frame not being flushed — tmux
holds the paint after "begin sync" and only the pane-switch full-redraw clears it.
tmux advertises the sync feature to the client, so if 2.1.200 changed how/when it
emits begin/end-sync (or emits an unbalanced pair), tmux would sit on the frame exactly
like this. (Shared as a hypothesis, not a confirmed root cause.) Whatever the change
was, it shipped in 2.1.200, not 2.1.201.

Workaround

Native install keeps prior versions on disk; repoint the symlink back to 2.1.199:

ln -sfn ~/.local/share/claude/versions/2.1.199 ~/.local/bin/claude

then relaunch Claude Code (a running session keeps its in-memory binary, so the
rollback only takes effect on a fresh launch).

Possibly related

• #29937 (open) — general tmux rendering corruption. This report adds a precise

199→200 regression window which that issue lacks.