[BUG] Terminal rendering corruption in tmux - text overlaps and overwrites previous output

Still reproducing on the latest Claude Code release in tmux on Linux.

I don’t think this should go stale: newer TUI rendering issues like #35356 and #35803 look plausibly related, and the core symptom here remains the same — the UI render state appears to drift and overwrite existing terminal content, making the session unreadable.

I’m also still seeing the repeated auto-scroll/jump from the top to the end of the session, which makes the rendering instability noticeably worse, especially on remote machines where the TUI is the only interface. Terminal redraws still don’t recover it; /clear or restarting is still the only reliable workaround for me.

I’d suggest keeping this open as a canonical tracker for this class of TUI/tmux render-corruption bugs unless there’s already another root issue intended to supersede it.

Yes, this is still an issue in 2.1.79. And my use case is exactly as @WingsOfPanda describes: remote machine where TUI is the only interface.

Still experiencing this on v2.1.74 in VSCode's integrated terminal on macOS (Darwin 25.3.0). Two symptoms:

1. Scroll jumping — scrolling up during output causes the terminal to snap back to the top (not bottom), making it impossible to review previous output
2. Rendering corruption — intermittent garbled/overlapping text that requires restarting the terminal

Both issues have gotten worse recently and now occur in all projects. /clear helps temporarily but the scroll issue returns immediately when new output is streamed.

Yes - I've been having this issue in TMUX session in iTerm2 on MacOs 26.2 for the past week or so. It makes AskUserQuestion tools usage unusable as the selection line renders in the wrong position and text overlaps all over the place.

Resizing the window forces a redraw, so the AskUserQuestion tool can be used properly, but then it just corrupts text again on the next turn.

Also have the scroll jumping issue as well

this is a huge issue. love claude code but this makes it really really hard to use

hey. it's fixed at the terminal level here

https://github.com/Dcouple-Inc/Pane/pull/120

open source, using xtermjs which is the same terminal as VS Code. feel free to copy this fix or download the latest release to run claude code on any operating system with the fix in place. i was so mad and frustrated at this that I had to fix it myself.

Not just a scrolling issue — also a rendering/layout problem in VS Code's side-by-side panel mode. When Claude Code runs in VS Code with the terminal on one side and the editor on the other, text formatting breaks in unpredictable ways. Options and multi-line output get weirdly split left-right, text wraps incorrectly, and the whole experience feels janky rather than fluid. Combined with the scroll-jumping, longer sessions in VS Code become genuinely hard to follow. This isn't just macOS standalone terminal — it's very much a VS Code integrated terminal issue too.

yeah i had to switch off cursor/vscode and build myself an ide that managed xtermjs (the library they both use) well enough for the complex TUIs to not break.

works great and i have a fix for the scroll jump i just implemented rn here

https://github.com/Dcouple-Inc/Pane/pull/120

Happens in Konsole too.

Still seeing this on Claude Code v2.1.138 with Ghostty on macOS, over SSH into a tmux session on a Linux remote.

In my case, this appears to be Ghostty-specific: the same remote tmux session works normally from macOS Terminal.app, and also works normally from Windows Terminal. Forcing a more conservative TERM value did not resolve it in Ghostty.

Yes, as a TUI, I would anticipate that claude code would not get corrupted after about 1 minute of use when simply running in a tmux pane via ssh. But it does, much the OP describes, except it really just seems to stop. Everything else in the ssh/tmux session keeps working. iterm2 is running on macOS 15.7 host, with the macOS 26 guest VM being ssh'd into, where claude is allowed to run. (What is the path to success? If I find out, I hope to come back and comment here with an answer.)

I've been having a problem for days using Tmux within iTerm2 for CloudCode. What happens is that when I have multiple CloudCode sessions through Tmux, and I navigate between them, I see text from one session in another when I scroll up the terminal in iTerm2. But today I verified that this doesn't happen, for example, through the Warp terminal. Finally, I found this open issue.

I also am experiencing issues where the rendering gets entirely messed up. I am using 2.1.169 (Claude Code).
I do not have set -g focus-events on, but it gets corrupted while i have multiple claude sessions open. Ctrl+L fixes it until the next render. The dimensions of the pane have not changed, and the rendering is still messed up.

I am using tmux 3.5a in ghostty on a mac.

Started reproducing for me after upgrading to 2.1.168 on macOS.
Probably was reproducing before, previous version was 2.1.149 and I did not remember any issues.

Also started reproducing after being forced to upgrade to 2.1.169 on macOS (did not let me open agents from claude agents view until I updated).

Forcing a re-draw by resizing or creating a new tmux split corrects the corruption.

<img width="1407" height="223" alt="Image" src="https://github.com/user-attachments/assets/c9757cbd-fa1b-42f1-ae80-45022de3d877" />

Facing this same issue on macos too. Was working fine until last week; started noticing this issue only this week.

Still reproducible on v2.1.170 — and also on macOS (this issue is labeled platform:linux, but I hit the exact same corruption on macOS, so it doesn't appear platform-specific).

Environment

• Claude CLI version: 2.1.170
• Operating System: macOS 26.4.1 (Darwin 25.4.0)
• Terminal: WezTerm (20240203-110809-5046fc22) + tmux 3.6a
• TERM: tmux-256color
• Platform: Claude Max subscription

Symptoms (matching OP)

During long sessions while Claude Code is executing tools, the TUI gets into a corrupted state:

• Lines from different UI regions overlap and overwrite each other (spinner/status lines merged into code diff lines, tool output mixed with permission prompts)
• The session feedback prompt ("How is Claude doing this session? 1: Bad 2: Fine 3: Good 0: Dismiss") gets duplicated many times across the scrollback, interleaved with unrelated output
• No pane resize involved; happens mid-execution on its own

Ctrl-L and tmux redraw don't fix it (consistent with OP's analysis that the corruption is in Ink's virtual buffer, not the terminal). /clear or restarting the session does.

tmux config (relevant lines, same ballpark as OP's ruled-out config)

set -g default-terminal "tmux-256color"
set -as terminal-overrides ",xterm-256color:Tc"
set -s extended-keys on
set -as terminal-features ',*:extkeys'
set -g escape-time 10
set -g focus-events on
set -g history-limit 50000
set -g mouse on
set-option -g status-position top

Worth noting: the v2.1.160 changelog includes "Fixed tmux/Apple Terminal rendering artifacts", but this corruption still occurs on 2.1.170 inside tmux.

No tmux and ssh isn't required to reproduce. Wezterm and Ghostty both have corrupted output on my mac.

Note: this issue is also not unique to linux even though the issue is labeled with platform:linux.

This is kind of wild how long the turnaround is on a fix here, it makes CC borderline unusable, surely someone internal is feeling this pain also? I cant imagine any other company this size having their flagship this broken, this long...

Mac/GhosTTY/TMUX.

I don't see the issue in this version:
claude install 2.1.158

I keep checking to see if any new versions fix it, but they all seem to corrupt the terminal quite quickly.

set -s escape-time 0
set -g default-terminal "tmux-256color"
set -as terminal-features ',*:RGB'
set -as terminal-features ',*:clipboard'
set -g set-clipboard on
set -s extended-keys on
set -as terminal-features 'xterm*:extkeys'

Does anyone from anthropic actually look at these issues? Or is this just triaged by ai now?

Claude code ludicrously broken because of this bug. Is there irony in advertising models world ending capabilities while a tui rendering issue is seemingly unaddressable

The same issue outside tmux on MacOS/Ghostty

Exact same issue, using Tmux and iTerm on MacOS. This is really annoying.

As a workaround Ctrl+Z -> fg also works to reset normal output.

as per @mbsulliv on a related issue, disabling vim mode has stopped this issue for me for the moment it seems.

Still reproducing on iTerm2 (macOS, no tmux), and the trigger is very consistent for me: switch to another tab in the same iTerm2 window and switch back → Claude's next output starts redrawing from the top of the window and overwrites existing on-screen text.

Details / data points:

• Started ~mid-June 2026. Previously I only saw this during /compact; now any tab-switch-and-return triggers it, and it's reliably reproducible that way.
• Resize-to-redraw did not recover it for me (contrary to what worked for some others here), and Ctrl+L also failed. The only thing that cleared it was Ctrl+K (clear iTerm2 scrollback) — which fixes the corruption but destroys all scrollback context.
• Behavior is consistent with render-state drift accumulating over a session: after a full Ctrl+K clear it behaves for a while, then the corruption returns once enough redraw/focus events pile up. App-level repaints (resize, Ctrl+L) don't help because the drifted cursor position just repaints wrong again; only resetting the terminal's own buffer (Ctrl+K) recovers it.

Plain iTerm2, no tmux involved here, so this isn't tmux-specific. Happy to provide a screen recording if useful.

<img width="1512" height="812" alt="Image" src="https://github.com/user-attachments/assets/f6b1666d-ddb3-4a03-85fa-f926d498dbaf" />

I'm getting this issue on inbuilt Terminal on Mac

From what I can see, vim mode seems to be the common thread. Can other people confirm this? @grunsab @imsurat

@jeffreymrusselleco Mine is set to standard mode, and not vim mode, according to the config settings.

Can't confirm that setting editor to standard mode is a functioning workaround. For me it now takes longer before the issue surfaces, but in the end output on scrollback/resize corrupts the same.

Only working workaround for me is downgrade: https://github.com/anthropics/claude-code/issues/29937#issuecomment-4708268706

Edit: living without vim bindings is not living, anyway.

Edit 2: have to concede that vim mode _also_ plays a role. Still getting corrupted output even in downgraded client version, if in vim mode. Switching back to normal mode.

(This is really quite horrible.)

@ jeffreymrusselleco, yes, I can confirm this. With standard mode, I was seeing it only after the compact finished. With vim mode I see it much more often. Missed adding this in my comment yesterday.