[BUG] Terminal Scrollback Buffer Rewind Lag in Claude Code + Tmux + Visual Studio Code After Extended Use

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/1413
2. https://github.com/anthropics/claude-code/issues/947
3. https://github.com/anthropics/claude-code/issues/1495

If your issue is a duplicate, please close it and 👍 the existing issue instead.

🤖 Generated with Claude Code

Update: boosting the tmux's history-limit to a ridiculously high number (e.g. 250'000) seems to delay the manifestation of the problem.

Update: resizing the tmux panes for even just one line/column seems to reduce the lag tremendously.

Also see this same kind of behavior in the VSCode extension’s pane, often when switching files or clicking around in a file. I also see this in the terminal if there's a lot of scroll back and you're presented a menu and hold down the up/down arrows (which I guess advance the selected menu item faster than the display updates, which causes this scroll bug (?), since it doesn't happen if you just press up/down slowly).

This is happening more and more lately even with little context. Major bug that can really mess up development progress.

+1

Happening on kitty too

Borderline unusable when this happens.
How complex would the transition from Ink to another TUI lib be?

Same Issue in VSCode Remote SSH Environment (macOS → Ubuntu)

Environment:

• Local Machine: MacBook Air M4, macOS
• Remote Server: Ubuntu (connected via VSCode Remote SSH)
• Terminal: VSCode Integrated Terminal
• Claude Code version: 2.0.34

Problem Description:

I'm experiencing the exact same terminal display corruption issue, but specifically in a VSCode Remote SSH environment.

When Claude Code starts working on tasks (code generation, research, file operations), the terminal display becomes completely corrupted after a few minutes. Both Japanese and English characters become unreadable - not as encoding issues, but as complete display corruption where nothing makes sense.

Why This Matters:

The entire value proposition of using Claude Code in VSCode is the seamless integration - instant file access, side-by-side code editing, integrated debugging, etc. Using a separate terminal as a workaround completely defeats this purpose and makes the tool much less useful.

Current Workaround:

The only solution is to restart VSCode entirely, which is extremely disruptive and breaks the flow of development.

Impact:

This issue makes extended Claude Code sessions practically impossible in what should be the ideal environment for using it (VSCode + Remote Development). It's been 3-5 months since the earliest reports of this issue, and it significantly impacts developer productivity.

Request:

Please prioritize fixing this terminal buffer/display issue, as it's a critical blocker for using Claude Code in professional development workflows.

Thank you!

This issue is really frustrating—I encounter it every day when using tmux.

I typically run CC in a tmux session on ubuntu 24.04 from iTerm 2 on a Mac. Only solution is to summarize the conversation, /quit, start claude again and hand it the summary. Clunky, and not always great.

Running into this in tmux inside iterm2. Tends to happen with very long conversations and makes Claude Code essentially unusable.

@anthropic this issue should be fixed. Claude Code must be compatible with tmux, it is too valuable in CLI flows.

Why this is not fixed yet? I've encountered this in Windows Terminal and macOS vscode and etc. Very annoying.

Same issue in VS Code Devcontainer + Oh My Zsh

I'm experiencing the exact same scrollback buffer rewinding issue in a different environment.

Environment

• Claude Code CLI (Not Extension): v2.0.58 (installed via devcontainer feature, manually updated)
• OS: macOS (host) → VS Code Devcontainer (Debian bookworm)
• Terminal: VS Code integrated terminal
• Container: node:22-bookworm-slim
• Shell: zsh with Oh My Zsh (via devcontainer features)

Devcontainer Configuration

"features": {
  "ghcr.io/anthropics/devcontainer-features/claude-code:latest": {},
  "ghcr.io/devcontainers/features/common-utils:latest": {
    "installZsh": "true",
    "installOhMyZsh": "true",
    "configureZshAsDefaultShell": true
  }
}

Symptoms

After accumulating scrollback history, the terminal violently flashes/scrolls from the beginning of the session to the current position on every interaction. This makes Claude Code completely unusable in devcontainer environments.

See attached video demonstrating the issue.

https://github.com/user-attachments/assets/78b1ee9e-8f82-44a3-8985-0e944734ee7a

This is a critical blocker for using Claude Code in containerized development workflows.

The issue seems to be Claude Code's reliance on ink.js and the library's improper rendering of its widgets. I couldn't wait for a proper fix so I "solved" it by vibe coding a pager interface that renders Claude Code's output into a TERMINAL_WIDTH × TERMINAL_HEIGHT virtual buffer at 60fps using xterm.js. You can check it out on my GitHub profile. There's a little bit of flicker in Windows Terminal (but then again, CC shows this also, so it's a problem in the terminal app and not xterm.js), but works like a charm in VS Code. Anyway, use at your own risk etc.

I'm using Ghostty → tmux → Claude Code.

Output volume is directly proportional to performance. And that degrades the longer the total history buffer is.

After one compaction, running a few subagents can easily hit 100% CPU on both Ghostty and tmux.

This is a SERIOUS bug, I am consistently waiting for it to rewind. When prompted for input with options to choose 1, 2, or 3, with 3 typically being "something else" where you type in a response, the rewind will happen on EVERY keystroke in that input.

I am seeing the behavior reported by @zinglax on v2.0.76. More information at https://github.com/anthropics/claude-code/issues/3648#issuecomment-3702562886

same on my side 👎 looking for solution dear community!

Why isnt this fixed yet @bcherny

I can report that this is better in 2.1.15. I still see some occasional issues, but it behaves FAR better with the new rendering. Performance is better overall.

Note: this is compared to 2.1.14 and below, not based on "a normal TUI". It's still a heavy hitter in terms of CPU, just not ridiculous.

I can report that this is better in 2.1.15. I still see some occasional issues, but it behaves FAR better with the new rendering. Performance is better overall.

Yeah, they implemented cell based diffing where they, well, basically diff the whole history each frame, every frame. On my laptop, this takes about 47% of CPU time towards the last 10% of the context. The context itself is not the problem, the problem is the myriad of ink.js widgets that react re-renders each frame, the allocation of the new buffer from to store the new state and the diff function that compares each line of the new buffer with the previous one (worst case about half the CPU time!) which gets progressively computationally heavy with the buffer(s) growth. No list virtualization either. For more info: https://dev.to/vmitro/i-profiled-claude-code-some-more-part-2-do-androids-dream-of-on-diffs-2kp6

I'm still curious why they have to mess with the scrollback buffer at all. VT console codes allow you to set scroll regions so you can have a non-scrolling bottom where the inputs are, and the rest is scrolled. No need to ever rewrite that.

+1 I have met the same issue with Cursor IDE, when resizing the window and the terminal scroll downing...

The CC got slow after that...

for me I mostly saw the flickering when the window pane in tmux was not very tall. I almost never saw it when the window was taking up the full monitor height. Now with the new patch I see some really annoying flickering which appears like an occasional flash even when the window is maximized. Quite annoying and I'd even consider downgrading to a previous version because of that.

At this point for sessions with a lot of output, the scrolling kills tmux. this is a new problem but just happened to me yet again. Issue happens in Ghostty and Wezterm.

Confirming this is still occurring on Claude Code v2.1.74, Windows 11 Pro (10.0.26200), Opus 4.6.

Trigger: Heavy tool use session (~60+ tool calls, 65%+ context usage). After writing a checkpoint to a large session file (~2000 lines), the entire conversation history re-rendered in the terminal — every tool call, diff, and response replayed from partway through the session. Captured 8,636 lines of duplicated terminal output.

Environment:

• Windows 11 Pro (not WSL, not tmux)
• Standard terminal (not iTerm2)
• 3 MCP servers registered (stdio-based)
• Multiple Edit/Bash/Read calls in rapid succession

Observation: The re-render appears to start from a mid-session point (not the very beginning), suggesting it may be triggered by a specific repaint event rather than a full session replay. In our case it started replaying from approximately the point where a large file edit was displayed.

This is a significant usability issue for long working sessions — the terminal becomes unusable during the replay and the duplicated output makes it difficult to find the actual current state of the conversation.

/tmp/issue-4851-answer.md