Repository navigation
[BUG] Terminal rendering corruption in tmux - text overlaps and overwrites previous output #29937
Description
Environment
- Claude CLI version: 2.1.63
- Operating System: Ubuntu (Linux 6.8.0)
- Terminal: tmux inside alacritty/standard terminal emulator
- TERM:
tmux-256color - Platform: Anthropic API
tmux configuration (ruled out as cause)
set -sg escape-time 10
set -g default-terminal "tmux-256color"
set -ga terminal-overrides ",xterm-256color:Tc"
set -g history-limit 50000
set -g focus-events on
alternate-screen is on (default).
Bug Description
During normal Claude Code sessions in tmux, the terminal rendering becomes corrupted. Text from different parts of the session (code output, permission prompts, previous responses) overlaps and overwrites each other on the same lines, making the interface unreadable.
This is not caused by:
- Resizing tmux panes (happens without any resize)
- Incorrect TERM settings
- Missing tmux configuration
The corruption appears to be in Ink's internal render state — the line positions it caches become out of sync with what's actually displayed. Once corrupted, neither Ctrl-L (terminal redraw) nor tmux's redraw (prefix + r) fixes it, since the problem is in Ink's virtual buffer, not the terminal's.
Steps to Reproduce
- Run Claude Code inside a tmux session
- Have a multi-turn conversation with tool calls (Bash commands, file reads, etc.)
- Eventually the renderer gets into a corrupted state where new output overwrites previous text
The trigger seems to be Ink's full-buffer redraw cycle — particularly when permission prompts appear mid-render, but it also happens during normal streaming output.
Expected Behavior
Text should render sequentially without overlapping. New output should appear below previous output.
Actual Behavior
Text from different render cycles (code blocks, permission dialogs, streaming responses) is drawn at overlapping positions, producing garbled/unreadable output. The corruption persists until the session is restarted.
Workaround
Only reliable fix is /clear or restarting the session.
Related Issues
- [BUG] In-progress Call causes Screen Flickering #769 — Screen flickering caused by full-buffer redraw on status indicator updates
- [BUG] Console scrolling top of history when claude add text to the console #826 — Console scrolling to top of history when adding text
All three issues appear to stem from the same root cause: Ink redraws the entire terminal buffer on each render cycle rather than doing targeted line updates, and the calculated positions drift from actual terminal state over time.
Activity
WingsOfPanda commentedon Mar 19, 2026
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;
/clearor 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.
efloehr commentedon Mar 19, 2026
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.
jarnesjo commentedon Mar 25, 2026
Still experiencing this on v2.1.74 in VSCode's integrated terminal on macOS (Darwin 25.3.0). Two symptoms:
Both issues have gotten worse recently and now occur in all projects.
/clearhelps temporarily but the scroll issue returns immediately when new output is streamed.RJAFusion commentedon Mar 25, 2026
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
parsakhaz commentedon Apr 10, 2026
hey. it's fixed at the terminal level here
greenfield-inc/Pane#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.
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
greenfield-inc/Pane#120
KnightHawk06 commentedon Apr 13, 2026
Happens in Konsole too.
Kevin7Qi commentedon May 10, 2026
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.
u35253 commentedon May 23, 2026
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.)
12 remaining items
e-e-e commentedon Jun 15, 2026
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
TelpeNight commentedon Jun 17, 2026
The same issue outside tmux on MacOS/Ghostty
devyoyaku commentedon Jun 18, 2026
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.
jhogendorn commentedon Jun 18, 2026
as per @mbsulliv on a related issue, disabling vim mode has stopped this issue for me for the moment it seems.
imsurat commentedon Jun 22, 2026
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:
/compact; now any tab-switch-and-return triggers it, and it's reliably reproducible that way.Plain iTerm2, no tmux involved here, so this isn't tmux-specific. Happy to provide a screen recording if useful.
grunsab commentedon Jun 23, 2026
I'm getting this issue on inbuilt Terminal on Mac
jeffreymrusselleco commentedon Jun 23, 2026
From what I can see, vim mode seems to be the common thread. Can other people confirm this? @grunsab @imsurat
grunsab commentedon Jun 23, 2026
@jeffreymrusselleco Mine is set to standard mode, and not vim mode, according to the config settings.
nem75 commentedon Jun 23, 2026
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: #29937 (comment)
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.)
imsurat commentedon Jun 23, 2026
@ 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.
Redraw Ink TUIs after a tmux pane resize
Improve tmux responsiveness and history buffer for AI tools (#1457)
Improve tmux responsiveness and history buffer for AI tools (#1457)
meowcakes commentedon Nov 4, 2026
Still experiencing this with COSMIC terminal...
colrichie commentedon Nov 7, 2026
I'd like to add a data point that matches this issue closely.
Environment: Windows Terminal → SSH → tmux → claude CLI (Linux host)
What happened:
Version: the corruption happened on the version just prior to 2.1.319 — i.e. the auto-update that triggered the "Update installed" notice was the update to 2.1.319.
Recovery: /exit, then tmux kill-session to destroy the tmux session entirely, create a new tmux session, and claude --resume inside it. This fully resolved the corruption (now running cleanly on 2.1.319). Simple terminal-level fixes (resize, tab switch, tmux refresh-client) did not help — only destroying and recreating the tmux session + resuming did.
This matches the pattern described above (freeze that survives redraw attempts, only a full session restart fixes it), and in my case it appears to have been triggered right around an in-session auto-update.