Terminal keeps scrolling to top when conversation gets long

Still broken as of v2.1.81:

https://github.com/anthropics/claude-code/issues/36582
https://github.com/anthropics/claude-code/issues/35403
https://github.com/anthropics/claude-code/issues/36816
https://github.com/anthropics/claude-code/pull/35683
https://github.com/anthropics/claude-code/issues/33814
https://github.com/anthropics/claude-code/issues/34845
https://github.com/anthropics/claude-code/issues/33367
https://github.com/anthropics/claude-code/issues/34400
https://github.com/anthropics/claude-code/issues/826
https://github.com/anthropics/claude-code/issues/36621
https://github.com/anthropics/claude-code/issues/36128
https://github.com/anthropics/claude-code/issues/35766
https://github.com/anthropics/claude-code/issues/34242
https://github.com/anthropics/claude-code/issues/18299

A huge hit to productivity. You have to wait until the whole thing ends so you can read what the agent did...or you can fight the scroll in the meantime and still not be able to read anything..

Yes, it took me long time to figure out it was claude code issue. Just jumping around this way ....

please fix it

You can keep pressing the arrow key (↓) to down to see output if this happens

It is most annoying when Claude's output is a few screens back to read and I get a few seconds in then bam! scrolling. And holding in place with mouse or something does not work. I've not tried in tmux. Super annoying so now I wait til its done to scroll up and read it all.

I tested on both my windows 11 and mac and they BOTH have this problem. Checking issue history this seems to be getting ignored

i use it via tabby to ssh to a server and run claude on the server. after a while, claude starts scrolling up to beginning, so it's really disturbing.

Still hitting this on Claude Code v2.1.81 (2026-03-23).

Environment

• OS: Ubuntu 24.04.4 LTS on WSL2 (kernel 6.6.87.2), Windows 11 24H2 host
• Terminal: Windows Terminal → WSL2 bash (xterm-256color)
• Hardware: i7-9750H, 32GB RAM

Behavior

Every new line of output causes the window to jump back to the top of the conversation. Gets progressively worse as the session grows longer. Makes it impossible to follow streaming output in real time.

Notes

• Happens consistently regardless of output type (code, text, tool results)
• /clear temporarily fixes it until the session grows again
• No terminal-side scroll lock or alternate screen buffer settings make a difference

Version: 2.1.81

Can confirm — this is really frustrating. It keeps jumping back to the top after every turn, which makes it hard to follow. This seems like a new bug introduced in a recent version; didn't experience scrolling issues for quite a while now.

It's strange that you can't just go and say: hey, Claude, fix this!

👍 We're experiencing the same issue embedding xterm.js 6.0.0 in a Tauri app. The scroll position jumps when Claude Code redraws its TUI while the user is scrolled up. Confirmed root cause: cursor-up sequences exceeding viewport height + ESC[2J/ESC[3J.

also having this issue, same as everyone else.

As noted earlier,

The scroll position jumps when Claude Code redraws its TUI while the user is scrolled up

And as such, this issue also occurs when _resizing_ a terminal window containing a claude code session that is scrolled up.

I'm using aerospace (i3-like dwm) on macOS and as a result, any workspace switch or window manipulation actually causes the window to be moved and resized, causing this issue.

Nothing more to add other than one more person experiencing this and REALLY annoyed by it.

It is impossible to read prior conversation while Claude is "working" - keeps scrolling back to the top.

Makes steering the conversation extremely difficult, as you have no idea what Claude has done. To say this is frustrating is an understatement.

Additional context: Claude Code running in browser via xterm.js + WebSocket PTY relay

Experiencing this same scrolling issue when running Claude Code inside a browser-based terminal (xterm.js v5.3.0 connected to Claude CLI via a node-pty WebSocket relay).

Environment

• Terminal: xterm.js 5.3.0 in SvelteKit web app (not native terminal)
• Backend: node-pty 0.10.1 spawning claude in a PTY, relayed over WebSocket
• Platform: macOS arm64, Node 20.0.0
• Claude Code: v2.1.84
• Access: Remote via Tailscale IP (HTTP, not localhost)

Reproduction

1. Open workspace at http://<host>:5174/workspace
2. Shell tab auto-launches claude --add-dir .
3. Start a conversation — after several exchanges, the terminal scrolls to top
4. Scrolling back down is immediately overridden by the next output chunk

Observations

• The xterm.js screenReaderMode: true setting may interact with scroll behavior
• The WebSocket relay sends raw PTY output without buffering — rapid small chunks may trigger xterm.js's scroll-to-cursor logic repeatedly
• This does NOT happen with plain shell commands (ls, git, etc.) — only with Claude's streaming TUI output

Workaround being tested

Considering adding output throttling/batching in the WebSocket relay to reduce scroll-triggering events during streaming output.

+1

Same here

Very annoying and makes it unusable

Having the same issue here, I can't even read what is goin on, everytime claude runs a comand it goes to the top of the session, and moreover it is anoying, when you can't even follow along in claude's thinking process.

2.1.87 improved that so it happens a few times a day only, not almost-every-time as before.

I'm on 2.1.89 on windows - in both Windows Terminal and Tabby it constantly scrolls back to the top after a few tool calls

Also still the same problem here, jumping all the time up
I'm on 2.1.89 but in OsX using terminal in VC (without IDE integration of Claude)

@ericflecher We tracked this down in our Electron + xterm.js + node-pty setup (very similar to yours).

Root cause: Claude's TUI sends \x1b[2J\x1b[3J (clear screen + erase scrollback) during streaming repaints. The ED3 (\x1b[3J) sequence resets xterm.js's viewportY to 0, which is what causes the jump to top.

We confirmed this by logging xterm's onScroll event with stack traces — every viewport jump traced back to eraseInDisplay in xterm's InputHandler.ts.

Fix (two parts):

1. Upgrade from xterm 5.3.0 to @xterm/xterm 5.5.0 — includes a synchronous output fix (PR xtermjs/xterm.js#5453) for the related issue xtermjs/xterm.js#5620. Reduced the frequency but didn't eliminate it.

1. Strip ED3 from the TUI repaint pattern before writing to xterm — only when paired with ED2, so standalone clear still works:

``js
const filtered = data.replace(/\x1b\[2J\x1b\[3J/g, "\x1b[2J");
terminal.write(filtered);
``

This has eliminated the scroll-to-top issue in our testing.

Does Anthropic have a fix plan for this issue?

the most annoying issue ever

The code is open source now — fix it yourselves!

The code is open source now — fix it yourselves!

It would be considered a "third party harness" and blocked from subscriptions xD

i think yall can just fork and fix this yourselves, the code leaked a week ago and opensourced yesterday. I know the scrolling glitch is annoying but in this vibe coding era, do fix the things that annoy you, dont rely on anyone

Same experience here in VS Code's integrated terminal (macOS). Beyond the scroll-to-top jumps, the rendering itself is off — when running Claude Code in a side-by-side layout (terminal + editor), text gets formatted strangely across the available width. Option lists and structured output don't render cleanly. It's not a smooth experience for longer conversations.

+1 When will there be a fix for this?

https://x.com/bcherny/status/2039421575422980329

export CLAUDE_CODE_NO_FLICKER=1 I think there is an update

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

https://x.com/bcherny/status/2039421575422980329 export CLAUDE_CODE_NO_FLICKER=1 I think there is an update

I have been testing it for 4 days, and it doesn't seem to help.

Dcouple-Inc/Pane#120

It's not working. I've been trying it all day today on Windows 11, and it still scrolls upwards. It's not as bad as Windows Terminal, but it still scrolls up.

> Dcouple-Inc/Pane#120 It's not working. I've been trying it all day today on Windows 11, and it still scrolls upwards. It's not as bad as Windows Terminal, but it still scrolls up.

Dang what environment? I'm on windows with WSL and it's fine since I implemented this. I have my terminal set to git bash in the pane settings. Do you?

Dang what environment? I'm on windows with WSL and it's fine since I implemented this. I have my terminal set to git bash in the pane settings. Do you?

WSL2 Ubuntu: In the settings, "Auto-detect" is enabled. The problem only started occurring once the conversation became very long.

> Dang what environment? I'm on windows with WSL and it's fine since I implemented this. I have my terminal set to git bash in the pane settings. Do you? WSL2 Ubuntu: In the settings, "Auto-detect" is enabled. The problem only started occurring once the conversation became very long.

Hm. What version of CC are you on? It shouldn't matter tbh since this should be at the terminal level but I'll investigate

Hm. What version of CC are you on? It shouldn't matter tbh since this should be at the terminal level but I'll investigate

v.2.1.101