[BUG] Console scrolling top of history when claude add text to the console

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

A video example of this issue occurring. I'm not pressing/touching anything here. Very frustrating when it happens and forces you to stop working for up to 30 seconds from my experience.

https://github.com/user-attachments/assets/55569d1d-4d1e-4fe2-b178-d3fb8502c4ed

sane problem here, seems to pop up sporadically i can't pinpoint what triggers - i can sometimes work for hours with large volumes without issue, however when it starts clearing the terminal doesn't help

I have the same problem with Linux. It just started a few days ago. If I scroll up to read the latest output, it will jump to the first message, and I have to scroll back down. It's as if it triggers a refresh or background process timer and scrolls to the top.

Upgraded to 1.07, no change.

https://github.com/user-attachments/assets/73cb548f-a5f4-431b-af09-9db276953341

I'm experiencing the same thing on VS Code's integrated Ubuntu (WSL2) terminal on Windows 11.

Same here (WSL2/Ubuntu on Windows 11), in both VS Code's integrated terminal and Windows PowerShell.

Only happens when I scroll up to read some text during a Claude prompt (like when reviewing a long diff), it will then jump to the top of the scroll buffer after some periodic delay and then I have to scroll back down.

I'm fairly certain whats happening is the terminal line limit is hit in cursor/vscode and the way that claude code is managing the lines on the screen causes it to reprint everything or something. Raising the line limit in vscode/cursor didn't help but if I use claude code in just normal terminal it works great.

Mine is doing the opposite, takes me to the bottom while I am trying to read using Ghostty

I have the same problem with Linux. It just started a few days ago. If I scroll up to read the latest output, it will jump to the first message, and I have to scroll back down. It's as if it triggers a refresh or background process timer and scrolls to the top. Upgraded to 1.07, no change. Screencast.from.2025-05-30.09-39-35.mp4

Happening to me too in IntelliJ IDE, using Claude Code in WSL 2. This is a really frustrating experience, makes reviewing whatever Claude Code is proposing to implement really difficult as it keeps just scrolling to the top while you're trying to read.

A similar issue in GNOME terminal 3.44.0 GNOME 42 (Ubuntu 22.04):

The terminal scrolls up every 10-20 seconds when Claude outputs the diff file for proposed changes and then asks the question with 3 options:
Do you want to make this edit to _such and such file_? │
│ ❯ 1. Yes │
│ 2. Yes, and don't ask again this session (shift+tab) │
│ 3. No, and tell Claude what to do differently (esc)

This only seems to happen when viewing a diff with proposed changes.
This issue doesn't occur when scrolling to the very bottom of the terminal (where Claude asks I we want to make the edit).

Workaround solution:
Select one of the 3 options. Then it stops scrolling up while you're reading the diff file.

Same issue happens to me. As I scroll to read the output, it jumps all to the way to the top. Even in a short conversation thread. Please fix. It's in the built in terminal, VSCode or any other IDE and the terminal itself (Ghostly for me, but it's for any terminal).

This is extremely annoying. The workaround mentioned by @NathanSmeltzer didn't work for me with Wezterm on macOS. For now I run Claude Code in a tmux session. Entering the copy mode to scroll in the scrollback buffer stops the constant screen refreshes.

New update came out and I want to cautiously say the scroll to Top issue has disappeared. Been going for 1 hour without issue, hoping it stays this way.

Same issue, WSL2 on Windows 10 inside a bash terminal in VS Code. Copy/pasted something in and it just started scrolling to top and bottom (flashing) indefinitely. Doesn't seem to be the case in a non VSC terminal - it still flashes on larger copy/pastes but not between top/bottom, instead the text just briefly flashes and then keeps working as it should.

+1

1+

+1. Cursor in WSL

+1

same here with macos terminal (iTerm2), if the diff is larger than terminal window frame, scrolling is super annoying

https://youtu.be/ETTTBCsqTsI

That's a very big issue making Claude Code hard to use in WSL and Visual Studio Code. It keeps scrolling all the way up and sometimes gets stuck in a scrolling loop.

yes, here also - using Cursor as IDE

What is the best workflow to deal with this issue until we have a fix? Claude Code in a completely separate terminal?

Having same issue on SSH on cursor

same issue, please fix

Same issue, Windows 11, Ubuntu WSL in Cursor

Same issue, Windows 11, Ubuntu WSL in Cursor

+1

Same problem in vscode , if you even think of touching the terminal to resize it for example its starts and running through all chat history while being unresponsive.

Hope claude can fix this issue soon with the help of claude code.

I'm experiencing a similar issue, macOS latest version and iterm2. Video here, alongside more reports of people experiencing the same issue:

https://www.reddit.com/r/ClaudeAI/s/N51c3BmF6T

same exact thing with iterm2, and mac osx, anyone have a fix yet?

Same issue on WSL in a dedicated windows or inside cursor

🧢💍

Noticed this starts happening after a certain context size is reached in the terminal. Compacting helps, restarting helps. Long terminal histories experience this issue the closer you get to "0% context remaining before auto-compact".

Sometimes it will get into a state where it just never stops scrolling. This has literally crashed my entire VSCode multiple times. I've also noticed that the longer a conversation, the more compactions, the more likely this issue is to happen.

Can't help beyond that, but thanks for all the fish.

same here. extremely annoying issue. please fix it!

I think my eyes are going to roll

Same using Windows Terminal accessing WSL Ubuntu.

+1 ubuntu via wsl, win 11 terminal inside phpstorm

+1 I am experiencing this for claude code on my mac as well.

+1 Same issue here, seems to be getting worse and makes it almost unusable at times

I have to log work, exit and clear the console as a work around. Very annoying. I use tmux 3.4 on a Mac m1 pro with bash.

The way to fix this would be to not have it make the terminal program so windows-like

same problem. it does actually make it unusable a lot. Its a huge waste of time and a massive problem.

Just want to confirm the same, using MacOS, Cursor IDE, Ghostty Terminal and zsh

I have this issue on macOS/Kitty.

Same issue macOS/Ghostty

Another user mentioned it, but I want to make sure it's also clear that this behavior happens when the terminal window is resized. This can be either manually with the mouse, opening/closing a menu bar like the file explorer on the left or the chat interface on the right, or opening another terminal window in split mode.

I just want to be able to watch the actual prompt and not have it lockup and die while using it in cursor. If this crap starts its a good 15 minutes of wondering if i am ever going to see the prompt again or if all the work up to now just got thrown out the window. And its definitely related to the resize of the terminal window that claude code is in, but it affects a lot more than claude code, it locks up everything in cursor, entire application becomes on and off frozen.

I can confirm on macOS and IntelliJ as well!

EDIT:

This can be reproduced by:

1. Resizing the IntelliJ Claude Code terminal window,
2. Clicking on the window

Use Claude Code in 'Windows Terminal' from the Microsoft Store. It also works on WSL2 and whatever else you prefer, and you'll get rid of the frustration when the Node terminal in other editors freezes or scrolls uncontrollably.

!Image

Use Claude Code in 'Windows Terminal' from the Microsoft Store. It also works on WSL2 and whatever else you prefer, and you'll get rid of the frustration when the Node terminal in other editors freezes or scrolls uncontrollably.

how about mac?

Just wanted to follow up, the simplest way to duplicate this is to 1) have a long chat history that hasn't been cleared 2) trigger some long running query where it's researching, thinking, writing, compacting, whatever 3) while it's running that query paste in a large block of text and hit enter.

Seems to work for me about 90% of the time.

Bro, I just found workaround solution! use Warp terminal with Claude code and seem scrolling issue is solved! plus you got modern ai terminal.

Also in Windows Cursor by WSL

this is the worst thing about Claude Code, so far. happens every time I paste in large context.

why is this still here from april? can't they use claude to fix? lol

Just wanted to follow up, the simplest way to duplicate this is to 1) have a long chat history that hasn't been cleared 2) trigger some long running query where it's researching, thinking, writing, compacting, whatever 3) while it's running that query paste in a large block of text and hit enter. Seems to work for me about 90% of the time.

Yeah happens a ton to me using Serena MCP for writing memories and such.. it's kinda brutal when you're trying to develop. I'm also on Cursor with WSL.

macOS Cursor Claude Code IDE Integration, still seeing this issue. Any idea of a possible fix?

• one way around this is to ask it to read a file where you work with your code instead of pasting directly into the terminal, make the agent.txt say something like "when pressing keyboard key 2 go and read the prompt.txt file for new instructions". control characters can break the terminal.
• resizing/zooming out the terminal seems to be a general fix for now
• using tmux seem to fix it

i am guessing some mcp commands that output very long text snippets breaks it often

i am experiencing this issue with long running prompts where i dont clear the terminal, it happens on certain mcp commands and when doing / commands as well as compacting the conversation.

it wants to scroll through the entire history buffer before redrawing the terminal

have not checked yet but the interactive components like ctrl+r could be an issue.

this is seriosuly annoying, the time we are saving with AI is all wasted in watching the endless scrolling.

its the output of the sequential thinking, it's just spitting out raw json and the display constraints bug the f out. Big win would be to just parse that json data and output the sequential thinking in a properly formatted way - which would be a massive UX win for everyone as well

This has the label macos. I see the same in VS Code Terminal on linux when working in a dev container

I'm utterly surprised that such a major project is keeping such an obvious bug for so long. I really like Claude Code but I'm slowly going back to using Cursor instead due to this exact problem. I wish we had a non-CLI-based extension to use instead, CLIs with this level of complexity are terribly hard to get right.

I moved back to the terminal (rather than IntelliJ) until this gets fixed.

By far the biggest Claude Code bug by a very long stretch. It would be really great to get the attention of a dev on this.

+1

Don't take my word for it, but I suspect that v1.0.70 might have resolved this issue! I've not had this issue since upgrading earlier today. The CHANGELOG for v1.0.70 says this:

Performance: Optimized message rendering for better performance with large contexts

https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md#1070

Don't take my word for it, but I suspect that v1.0.70 might have resolved this issue! I've not had this issue since upgrading earlier today. The CHANGELOG for v1.0.70 says this: > Performance: Optimized message rendering for better performance with large contexts https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md#1070

My cc is v1.0.72. It still has this problem

Can confirm the issue persist, using windows + powershell. Impossible even to write because of the non-stop scrolling behaviour

Is there any workaround available?

By the way, claude works well in a separate window (w/o other tabs) of the
native MacOS terminal

вс, 10 авг. 2025 г. в 00:07, Amit Kumar @.***>:

westcottian left a comment (anthropics/claude-code#826) <https://github.com/anthropics/claude-code/issues/826#issuecomment-3172099329> Is there any workaround available? — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/826#issuecomment-3172099329>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BBSVOPSXYKR3EF4TSJQRK7T3MZPIHAVCNFSM6AAAAAB3O2S5FKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCNZSGA4TSMZSHE> . You are receiving this because you commented.Message ID: @.***>

Probably a bug in VSCode, which they won't fix any time soon, as they are very busy with Copilot. 😂

I've just started using iTerm2 on macOS with claude code and almost immediately got this warning.

"A control sequence attempted to clear scrollback history."

and went looking for a setting.

<img width="1019" height="400" alt="Image" src="https://github.com/user-attachments/assets/e5c6182a-9031-4eaf-94a6-309c41ab23c1" />

https://superuser.com/questions/555554/putty-clear-scrollback-from-commandline

Seems to suggest a putty specific command sequence to manage scrollback content. I clicked 'Always Allow' a few hours ago and haven't had the scroll go crazy since then.

Maybe useful to diagnose if it's not already understood - @ollie-anthropic

I think this bug is also related to vscode crashes.

long convo + pane resize = 💥

sometime you do not need to add text. It just happens

1.0.89 (Claude Code). MAC os

https://github.com/user-attachments/assets/ffd34df5-ac6e-472d-98d8-225562f683cd

same here

I've just started using iTerm2 on macOS with claude code and almost immediately got this warning. "A control sequence attempted to clear scrollback history." and went looking for a setting. <img alt="Image" width="1019" height="400" src="https://private-user-images.githubusercontent.com/13701/479742523-e5c6182a-9031-4eaf-94a6-309c41ab23c1.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NTYxOTk1MTUsIm5iZiI6MTc1NjE5OTIxNSwicGF0aCI6Ii8xMzcwMS80Nzk3NDI1MjMtZTVjNjE4MmEtOTAzMS00ZWFmLTk0YTYtMzA5YzQxYWIyM2MxLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTA4MjYlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwODI2VDA5MDY1NVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWI5YzE3YmY0YmRmNzgzN2M4NWVkYWY4ODAyYTVkYzJhNzk1ODhmMWY5N2VlMzY2M2NlNDYyYWRhMWE3YTNjNWYmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.6rDowBBgiwcXZ-WRvPQIBj2eQEX7LIwuDCI2YIjS8CE"> https://superuser.com/questions/555554/putty-clear-scrollback-from-commandline Seems to suggest a putty specific command sequence to manage scrollback content. I clicked 'Always Allow' a few hours ago and haven't had the scroll go crazy since then. Maybe useful to diagnose if it's not already understood - @ollie-anthropic

Still not had the issue? @stewarthaines ?

Still not had the issue? @stewarthaines ?

Fair question @haveaguess - I slunk away from this thread to watch from a distance when I kept seeing a similar, but seemingly more predictable interaction between the claude code terminal and my vscode /ide integration. Seems when the claude buffer is populated, and waiting for input, and I do anything in the ide then the terminal buffer jumps to the top of the buffer. It comes back with a direct keyboard input.

So. Different behaviour than I was seeing before, but I didn't dig any further. It's _less_ annoying now.

Same here on vterm mode in Emacs. Sending enter sometimes mitigates the problem.

I hate this one, can just someone fix it? Condex CLI and Gemini CLI don't have this issue when working on long time.

https://github.com/anthropics/claude-code/issues/826#issuecomment-3203622193 seemed to help a bit, not 100% though.

I switched to using Ghostty for just Claude Code and it does not seem to have this issue. I had some flickering issues in the status bar, but setting window-vsync = false solved the problem. It is missing a few key features that stopped me from migrating 100% from iTerm2- no scroll bar and no find functionality, but works great for just Claude Code.

This is my Ghostty config to match iTerm2 as closely as I could:

# Ghostty Terminal Configuration
# File location: ~/.config/ghostty/config
# Docs: https://ghostty.org/docs/config/reference
# Reload: Cmd+Shift+, (macOS) / Ctrl+Shift+, (Linux)

# NOTE: inline-comments are not supported in Ghostty config files

## FONTS ##
font-family = "MesloLGS NF"
font-size = 12
window-title-font-family = "GeistMono NFM"

## APPEARANCE ##
# https://moshen.github.io/iTerm2-to-Ghostty-Config-Converter/
# ~/.config/ghostty/themes/tango-dark
theme = "tango-dark"
# theme = "Monokai Remastered"
bold-is-bright = true
background-opacity = 1.0
background-blur = false

## WINDOW ##
macos-window-shadow = false
window-vsync = false

## CURSOR ##
cursor-style = block
cursor-style-blink = false

## SPLITS ##
unfocused-split-opacity = 0.9
split-divider-color = #75507b

## SHELL ##
# Allows cursor-style = block to work
shell-integration-features = no-cursor

## WORKING DIRECTORY ##
# Set default working directory for new windows and tabs
working-directory = inherit

# Ensure new windows inherit working directory properly
# window-inherit-working-directory = true

## KEYBINDINGS ##
# Shift+Enter for newline
keybind = shift+enter=text:\x1b\r

I see all the related issues are closed with this being the main issue to track this bug.

As of now, issue still persists and impacting a lot of users, maybe even all? Only workaround I know is to completely close VS Code and open again, which is not very efficient given that issue starts happening again shortly after.

This is extremely annoying. Primarily it happens on MCP calls. No workaround so far.

Yes. We solved it in https://devswarm.ai/ where you can use Claude Code instances in parallel branches on the desktop. After waiting months for it to be fixed, we finally solved it. And yes, that glitch IS that annoying! Anyone at Claude Code, message us, and happy to help you get this fixed!!

How did you manage to solve it? Or it's just marketing of your service?

> Yes. We solved it in https://devswarm.ai/ where you can use Claude Code instances in parallel branches on the desktop. After waiting months for it to be fixed, we finally solved it. And yes, that glitch IS that annoying! > Anyone at Claude Code, message us, and happy to help you get this fixed!! How did you manage to solve it? Or it's just marketing of your service?

Well we render the Claude CLI (and many others!) in our app, and found that if we append a SCROLL_TO_BOTTOM sequence to most of the IO (especially resizes, but the /help menu too would cause it really reliably!) the issue essentially disappears. It's a night and day difference!

Yes. We solved it in https://devswarm.ai/ where you can use Claude Code instances in parallel branches on the desktop. After waiting months for it to be fixed, we finally solved it. And yes, that glitch IS that annoying! Anyone at Claude Code, message us, and happy to help you get this fixed!!

lol, we fixed it, but have to message us to get the info, and we are not going to tell you how to fix it though. by the way we are are a service.

@jackstine sorry I also work work for DevSwarm if that wasn't clear here, essentially the thing to do is to append the terminal character sequence that signals a scroll to bottom to almost all IO between you and Claude. You'd have to wrap your CLI in something that can intercept the IO (xtermjs + node-pty for example) to apply the transform.

Mine goes berserk on Windows, Ubuntu and macOS - like a video-game gone wrong, with the entire chat-history scrolling past so fast it's unreadable. I call this "scroll-storming". It happens most when I paste a larger amount of text into the terminal prompt-box.

This basically makes it unusable about half the time. Seems like a scroll to bottom sequence is the hackjob of choice. Is there any simple way to work around this? I'm not very familiar myself with terminal hacking...

9/15/2025 still not fix this

9/17/2025 still not fix this.
This is very annoying.

Still having this issue on Linux with screen.

Still having this issue on Windows with screen

Same issue on Mac with tmux

Same issue, all the time. WSL

OpenAI Codex CLI: Open-source
Google Gemini CLI: Open-source
Claude Code CLI: Closed-source

Open-source generally wins, over time. The community really wants to help,too.

@anthropics any comment?

See above

> Yes. We solved it in https://devswarm.ai/ where you can use Claude Code instances in parallel branches on the desktop. After waiting months for it to be fixed, we finally solved it. And yes, that glitch IS that annoying! > Anyone at Claude Code, message us, and happy to help you get this fixed!! lol, we fixed it, but have to message us to get the info, and we are not going to tell you how to fix it though. by the way we are are a service.

Laugh at us all you want, but we are literally happy to let you know how we fixed it if that helps the Claude Code community. Email me at mike@twentyideas dot com and can setup a zoom with our CTO trevor.

See above > > Yes. We solved it in https://devswarm.ai/ where you can use Claude Code instances in parallel branches on the desktop. After waiting months for it to be fixed, we finally solved it. And yes, that glitch IS that annoying! > > Anyone at Claude Code, message us, and happy to help you get this fixed!! > > > lol, we fixed it, but have to message us to get the info, and we are not going to tell you how to fix it though. by the way we are are a service. Laugh at us all you want, but we are literally happy to let you know how we fixed it if that helps the Claude Code community. Email me at mike@twentyideas dot com and can setup a zoom with our CTO trevor.

Why don't you just post it here where it helps people instead of asking for someone from Anthropic to email you to set up a call with your CTO when it would be easier for them to just fix it because their engineers make like $600k/yr and THEY have the same visual bugs as us? but they're working on things so WHAT PURPOSE would they have to contact YOU for this precious fix?

They fixed it in their sleep last night, they just never pushed it in their mind.

IDK maybe they'll want to stop everything and zoom with your CTO

9/29/2025 still not fix this

This issue is really annoying. On VS Code Insider + latest Claude Code. I keep having to save my context to a file and restarting VS Code + my Claude Code session.

Claude Code was updated to v2.0.0 with sonnet-4-5-20250929 available (which is impressively fast). Over the last 30 minutes, I haven't encountered the eternal scrolling issue. While rapid scrolling still occurs, it stops shortly. I hope this isn't just a temporary observation.

Yes, after updating, it's improved, but not solved fully yet.

On Tue, Sep 30, 2025 at 1:09 AM Yusuke Watanabe @.***>
wrote:

ywatanabe1989 left a comment (anthropics/claude-code#826) <https://github.com/anthropics/claude-code/issues/826#issuecomment-3349221204> Claude Code was updated to v2.0.0 with sonnet-4-5-20250929 available (which is impressively fast). Over the last 30 minutes, I haven't encountered the eternal scrolling issue. While rapid scrolling still occurs, it stops shortly. I hope this isn't just a temporary observation. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/826#issuecomment-3349221204>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BCHXASSZ5DRSAL3UG3Y2S3D3VGU3DAVCNFSM6AAAAAB3O2S5FKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGNBZGIZDCMRQGQ> . You are receiving this because you commented.Message ID: @.***>

I just encountered the scrolling issue again with 2.0.1 so definitely not solved.

Still seeing crazy scrolls and it doesn't stop.

Still broken on 4.5 / code 2.0.1 for me

Interesting: the same eternal hyper-scrolling bug affects GitHub Copilot CLI. So it must be a bug in a common library.

I'm having this on Arch, inside Cursor and in Alacritty too

This is very annoying and still not solved :(
Using claude code as plugin inside cursor
I have seen it happen in the following occassions -

1. When you scroll up to see previous conversations
2. When you are in plan mode and claude code finishes planning
3. When you are in approve mode & claude makes changes
4. Resizing different panels, claude code terminal window
5. When context increases, somehow the scrollbar always goes to the top

@anthropics .... please communicate ... the community wants to help

My ass is already burning from this bug 😫

This should definitely be higher priority... I've been watching my chat log scroll for 5 minutes now, and it resets to the top every time an edit is made, so I can't tell if I need to respond to an action prompt or just keep waiting.

This should definitely be higher priority... I've been watching my chat log scroll for 5 minutes now, and it resets to the top every time an edit is made, so I can't tell if I need to respond to an action prompt or just keep waiting.

Use OS optimized terminal with GPU acceleration. Full scrolling will take about 1-2 sec in this case or almost instanly if you have something like nvidia rtx.

> This should definitely be higher priority... I've been watching my chat log scroll for 5 minutes now, and it resets to the top every time an edit is made, so I can't tell if I need to respond to an action prompt or just keep waiting. Use OS optimized terminal with GPU acceleration. Full scrolling will take about 1-2 sec in this case or almost instanly if you have something like nvidia rtx.

Which/How? This is especially annoying within VSCode's terminal.

> > This should definitely be higher priority... I've been watching my chat log scroll for 5 minutes now, and it resets to the top every time an edit is made, so I can't tell if I need to respond to an action prompt or just keep waiting. > > > Use OS optimized terminal with GPU acceleration. Full scrolling will take about 1-2 sec in this case or almost instanly if you have something like nvidia rtx. Which/How? This is especially annoying within VSCode's terminal.

Im using Claude Code CLI on remote Ubuntu, so just using third party terminal on my desktop to connect via ssh to remote claude console where this scrolling bug appears too. If u run Claude Code CLI on desktop pc this will work same. For VS extension... hm... idk, try to run IDE with discrete gpu if you have one. VS Code probably doesn't support hardware acceleration, check it. The key problem isn't the scrolling itself, but the fact that this scrolling is incredibly laggy without hardware acceleration of its display.

As per @siberianwm's suggestion, I set the GPU Acceleration for VSCode's Integrated Terminal to "on" (instead of auto, which is the default). For now this seems to not happen any more. Will update if anything changes.

<img width="1258" height="470" alt="Image" src="https://github.com/user-attachments/assets/f8b615e8-05e0-4dc9-b965-a959cc139762" />

I suspect this is linked to https://github.com/vadimdemedes/ink/issues/359 and https://github.com/vadimdemedes/ink/blob/6d84457705210dc87eb7dddf3225b05be16d7628/src/ink.tsx#L239 in particular. If I understand well, when rendering anything larger or equal to the height of the terminal, instead of erasing and rewriting a few lines, ink will reset the terminal including the scrollback buffer, move the cursor to the top left, then re-write the entire static output ever rendered + any new output ... every time it renders any output!

My suspicion is that clearing and setting the cursor home will scroll up, re-writing the output will scroll back down. Flickering. How bad it is depends on how the terminal handles it and when exactly it renders...

Edit: If I'm right, stty rows 9999 (setting the tty/pty height to a very large number) before starting claude might work around the problem as stdout.rows will be a large number. However this is usually reset when you change the terminal window size, and it might trigger other quirks...

come on team... have a look. this is super annoying.

As per @siberianwm's suggestion, I set the GPU Acceleration for VSCode's Integrated Terminal to "on" (instead of auto, which is the default). For now this seems to not happen any more. Will update if anything changes.

Same eternal-scrolling / hyper-scrolling issue on Windows Terminal and macOS Terminal.

They have GPU acceleration options:

Windows Terminal

• Windows Terminal uses GPU acceleration by default. You can configure it through Settings → Rendering
• Use software rendering (disable GPU): Toggle this OFF to use GPU acceleration (default is OFF, meaning GPU is enabled)

You can also set this in the settings.json file with: "rendering.software": false

macOS Terminal

• Terminal.app on macOS has limited GPU-related settings:
• Terminal → Settings → Profiles → Advanced tab
• Use Core Text renderer: When unchecked, uses the legacy renderer.
• The Core Text renderer (default) generally performs better with modern graphics

There's no explicit "GPU acceleration" toggle like in VSCode or Windows Terminal

So Windows Terminal with GPU acceleration shows the scrolling issue. And macOS Terminal with only limited scope for GPU shows the scrolling issue.

Think it traces upstream to Ink.

Anyone got any ideas for what to do here?

@dimension-zero
For me it works fine, scrolling hasn't disappeared, but it goes by tens of times faster, literally in 1-2 seconds.

I am experiencing this type of issue when I check very long server's log via ssh.
I think this is just common library's issue.

Claude performed research and summarized as follows:

• Scrolling Problem overview claude-code-scrolling-bug-overview.md
• Quick Potential Solutions: claude-code-quick-solutions.md

For Emacs Users:

• Potential workarounds for Emacs users: claude-code-emacs-vterm-guide.md
• My Emacs config 03-ui-000-vterm-10-optimize.el.txt
• In my case, this setup mitigates the scrolling issue in Emacs on WSL2. Also, it sometimes works to press Escapce and then Enter in turns.

This should be feeling better since yesterday. A couple more fixes incoming over the coming week.

Ironically enough, the fix (the new VS Code extension) doesn't like to scroll at all sometimes.

¯\\\_(ツ)\_/¯

I think I preferred the terminal even with the wacky scrolling bug, at least I could see and manage the background processes...

There is a not-so-good way,limit scrollback lines in the settings.

This should be feeling better since yesterday. A couple more fixes incoming over the coming week.

@bcherny Thanks for hard work. Is it possible to separate Claude Code into Stable Release (major versions) and Preview Release (minor versions) channels? Some people will prefer to wait for a Stable Release with full release notes etc.

This is happens to me only when a subagent/Task runs in the background.

Still happening on 2.0.14
https://github.com/user-attachments/assets/95d181f3-6241-4749-9396-d81f094b4ffa

I closed eyes again today.

This bug is so bad, if the crazy scrolling goes for long enough, it'll crash my IDE where I'm running the integrated console.

By far the biggest obstacle to using Claude Code, I'm glad it's on Anthropic's radar, completely destroys the usability of CC. Hopefully it's fixed soon!

This is driving me crazy 😵

on 2.0.20 and this issue still persists. It happens any time a sub agent is executing, OR any time a single threaded task has a long output.

<!-- Failed to upload "Screen Recording 2025-10-13 at 12.28.44 PM.mov" -->

My workaround that makes this significantly less-annoying (modify for your OS / setup):

iTerm2 keybinds:
Scroll to top: cmd+up-arrow / Mouse side button (front)
Scroll to bottom: cmd+down-arrow / Mouse side button (back)

Photosensitive Epilepsy

Photosensitive epilepsy (PSE) is a form of epilepsy in which seizures are triggered by visual stimuli that form patterns in time or space, such as flashing lights, bold, regular patterns, or regular moving patterns. PSE affects approximately one in 4,000 people (5% of those with epilepsy).

@chrislloyd Any updates on this? Its really a terrible experience and has been going on since April.

macOs 26.0.1 (25A362)

Cursor deets:
Version: 1.7.46
VSCode Version: 1.99.3z
Date: 2025-10-14T01:21:46.830Z (4 days ago)
Electron: 34.5.8
Chromium: 132.0.6834.210
Node.js: 20.19.1
V8: 13.2.152.41-electron.0
OS: Darwin arm64 25.0.0

I am able to reproduce multiple times a day.

this is driving me insane. i'm on mac os with iterm 2. when i scroll up a little while claude is working, to see the output it has recently generated, i get scrolled all the way to the beginning of the session. i can't read what claude is outputting while it works. i would really like to see what it is doing.

Its very very annoying. I am using the Max plan with $200 subscription. The tool has amazing capabilities but the automatic scroll to top is an issue.

I mostly use the plan mode. One of the workarounds is just to copy the output and paste in a different text editor like word etc.

From https://www.w3.org/WAI/WCAG21/Understanding/three-flashes-or-below-threshold.html

Success Criterion (SC) Web pages do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds. Note Since any content that does not meet this success criterion can interfere with a user's ability to use the whole page, all content on the web page (whether it is used to meet other success criteria or not) must meet this success criterion. See Conformance Requirement 5: Non-Interference.

From https://www.w3.org/WAI/WCAG21/Understanding/three-flashes-or-below-threshold.html > Success Criterion (SC) > Web pages do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds. > Note > Since any content that does not meet this success criterion can interfere with a user's ability to use the whole page, all content on the web page (whether it is used to meet other success criteria or not) must meet this success criterion. See Conformance Requirement 5: Non-Interference.

You're right: this hyper-scrolling issue might trigger epileptic seizures. We had a programmer who was severely epileptic and this is no joke. @anthropics please say something.

Same behavior on Windows 11, I noticed it multiple times

It might be random, but seems like zooming in/out somewhat helps ?

on windows 11 here running it in wsl in cmd
Claude Code v2.0.25

so still no fix?

This is a frustrating bug for anyone with epilepsy or light sensitivity - please fix this asap.

What's really weird is that even if I use /clear to clear the context window, when it starts doing this auto-scrolling, it's pulling back in the entire context from this session, all the way up until I logged in, no matter how many times I clear the context window. Like, how does it even know that old conversation stuff happened? This is horrible, I'm constantly waiting on it to finish itself so that I can continue. Has anyone figured out a solution? I'm running Ubuntu with Sql Server on AWS. I'm connecting through chrome browser and using Claude in the terminal inside the browser tab. zooming in/out and right-click tricks didn't work. I've not found any solutions. Please help :)

For the love of god, fix this. At least get involved with this discussion and let us know it's on your radar @anthropics

"Claude Code wrote 80% of its own code" 😄

For the love of god, fix this. At least get involved with this discussion and let us know it's on your radar @anthropics

@catherinewu as Claude Code project manager, can you guide us as how best to interact with you?

We have no way to know if our pleas are being heard so is there a better way?

Same issue. Most annoying. I wish you all great emotional dissatisfaction with life until it is fixed!!!!

Confirming this issue on macOS (Darwin 24.6.0) with Claude Code 2.0.31.

When the agent is actively working and generating output, any attempt to scroll up in the terminal immediately causes it to jump to the very top of the entire terminal session (the oldest output from when the terminal started). This makes it completely impossible to review recent command history or output while the agent is still running.

Every single scroll attempt is defeated - extremely frustrating for debugging or reviewing what just happened.

Same issue - I work around it by starting to type anything, and it scrolls me down, but I would love for it to be fixed.

This is still an active issue when using VSCode Terminal with Claude Code 2.0.31.

I also find the issue to be especially pronounced when there is a Bash task actively running with visible output taller than the current terminal window.

<!-- note to self: from discord: https://discord.com/channels/1072196207201501266/1354425630011166830/1434990466495021066 -->

The scrolling is, I fear, an unfortunate requirement of the ANSI terminal standard.

Here's a fun script to visualize what (I believe) TUIs need to do if they want to rewrite a block of terminal output.
Resize your terminal to be shorter than 10 lines to see the issues that CC is likely hitting: SCROLL_UP/_DOWN not only causes the terminal to scroll up and down, it also creates blank lines that need to be rewritten.

So likely CC or its underlying library is forced to scroll up, then rewrite all terminal contents from that point downward.

#!/usr/bin/env -S deno -A
// ANSI escape sequences for cursor movement
const CURSOR_UP = (n: number) => `\x1b[${n}A`;
const CURSOR_DOWN = (n: number) => `\x1b[${n}B`;
const CLEAR_LINE = "\x1b[2K"; // Clear entire line
const CARRIAGE_RETURN = "\r"; // Move cursor to start of line
const ENABLE_SCROLLING = "\x1b[r";
const SCROLL_UP = "\x1bM";
const SCROLL_DOWN = "\x1bD";

function randomNumber(): number {
  return Math.floor(Math.random() * 10000);
}

async function main() {
  const lines: string[] = [];
  for (let i = 1; i <= 10; i++) {
    lines.push(`Line ${i}`);
  }

  const e = new TextEncoder();
  async function write(s: string, d?: number) {
    for(const char of s) {
        Deno.stdout.writeSync(e.encode(char));
        await delay(5);
    }
    await delay(d);
  }
  async function delay(d = 500) {
    await await new Promise((resolve) => setTimeout(resolve, d));
  }
  write(lines.join("\n"));

  while(true) {
    await delay(1000);
    await write(SCROLL_UP.repeat(9));
    await write(CLEAR_LINE);
    await write(CARRIAGE_RETURN);
    await write(`Line 1: ${randomNumber()}`);
    await write(SCROLL_DOWN.repeat(9));
    await write(CLEAR_LINE);
    await write(CARRIAGE_RETURN);
    await write(`Line 10: ${randomNumber()}`);
    
    await delay(1000);
    
  }
}

main().catch(console.error);

The scrolling is, I fear, an unfortunate requirement of the ANSI terminal standard.

If this were the case, everyone would be having the same problem with all full-screen TUI apps. Vim, Emacs, less, screen, tmux, mc, and hundreds of others. It's possible to use the CSI cursor movement commands to overwrite character cells without redrawing the whole screen.

Is this a fullscreen TUI using the "alternate screen" or is it a bigger-than-fullscreen TUI which is not using the alternate screen and is making offscreen changes, reaching even farther than fullscreen?

Not being an apologist or anything, but I think that's the distinction.

EDIT: It's "alternate screen" not "alternative buffer." I always forget the official name. When comparing to tools like less remember that they use the "alternate screen" which is cool but incompatible with your terminal's scrollback buffer, since it needs to fully replace and emulate the concept of a scrollback buffer.

I do not think ANSI allows for making changes offscreen to the scrollback buffer; that’s for the terminal emulator to keep or throw away as it likes.

The alternate screen is most handy when you want to return the original contents of the terminal window after your application exits, yes, like less and vim do. But whether the alternate screen is being used or not, it seems like Claude or a library it uses is doing some unnecessary redrawing or doing it in a way that makes some terminal emulators think they need to append a lot of stuff to the scrollback buffer.

(I may be a decade or two out of date on this, but I believe there is no well-defined set of rules about what goes in to the scrollback buffer. There are a lot of heuristics once you get past “carriage return on the last line means capture the first line into scrollback and shift up”.)

I think it is more than that. I can do a /clear to clear the context, but
then when it starts doing this issue, it will pull the already cleared
context back in and start bouncing the screen.

On Mon, Nov 3, 2025, 8:34 PM paul cannon @.***> wrote:

thepaul left a comment (anthropics/claude-code#826) <https://github.com/anthropics/claude-code/issues/826#issuecomment-3483470447> I do not think ANSI allows for making changes offscreen to the scrollback buffer; that’s for the terminal emulator to keep or throw away as it likes. The alternate screen is most handy when you want to return the original contents of the terminal window after your application exits, yes, like less and vim do. But whether the alternate screen is being used or not, it seems like Claude or a library it uses is doing some unnecessary redrawing or doing it in a way that makes some terminal emulators think they need to append a lot of stuff to the scrollback buffer. (I may be a decade or two out of date on this, but I believe there is no well-defined set of rules about what goes in to the scrollback buffer. There are a lot of heuristics once you get past “carriage return on the last line means capture the first line into scrollback and shift up”.) — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/826#issuecomment-3483470447>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AF2YP4KMLR7PEKJ5FI3SG2T3277AXAVCNFSM6AAAAAB3O2S5FKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTIOBTGQ3TANBUG4> . You are receiving this because you commented.Message ID: @.***>

I do not think ANSI allows for making changes offscreen to the scrollback buffer

This is exactly my point, you've hit on exactly why we see the flickering: because CC is able to make changes offscreen to the scrollback buffer, and the only way it can do that is by using the SCROLL_UP and SCROLL_DOWN escape sequences (see my code example) which do cause the terminal emulator to generate blank lines, and do require CC to redraw large portions of the screen.

It is these SCROLL_UP and SCROLL_DOWN escape sequences, not CSI cursor movement (which is unable to do the necessary modifications to lines above the viewport) which trigger the flickering.

This is exactly my point, you've hit on exactly why we see the flickering: because CC is able to make changes offscreen to the scrollback buffer, and the only way it can do that is by using the SCROLL_UP and SCROLL_DOWN escape sequences (see my code example) which do cause the terminal emulator to generate blank lines, and do require CC to redraw large portions of the screen.

I had understood that SCROLL_UP and SCROLL_DOWN insert blank lines at the top or bottom of the screen, not allow changes to the scrollback buffer. Are you sure that's what's happening? What is being changed in the scrollback? That's somewhat alarming if so.

I would run your example code but it gives an error on the version of deno in Homebrew, and I'm not up to date enough on javascript to know if it's too new or too old or if it's a real bug.

$ deno --version
deno 2.5.6 ...

I'm no expert, but here's what I think is happening:

CC is using SCROLL_UP to move the cursor up past the top of the viewport -- this is the only way to reach up past the viewport -- and then issuing a command to the terminal to erase everything below that point. Then it rewrites everything below that point.

I guess that terminal emulators with scrollback buffers emulate this by going up into their scrollback buffer as far as requested, then erasing all lines from that point downward, and then writing new contents into the scrollback buffer. It's tricky because they're emulating a fixed-size viewport while still remembering everything that scrolls off the top, because that's what the end-user wants: to be able to scroll up and see more, older output lines.

My script doesn't do this perfectly, but from observing CC, that seems to be exactly what it is doing. A simple way to see this is to ask Claude to run a background bash script that outputs numbers, view the output, then resize your terminal like so:

> use bash tool to run this command
counter=0; while true; do echo $counter; counter=$((counter + 1)); sleep 5 ; done

Screenshot is from a random-number variant of the above, but hopefully my intent is clear enough
<img width="463" height="239" alt="Image" src="https://github.com/user-attachments/assets/430566c4-6a24-4942-91b8-a343eaa67aab" />

Then resize your terminal to be larger to confirm that, while your terminal was small, CC was still successfully updating lines outside the viewport.

Or perhaps I'm wrong and CC('s underlying TUI library) is responding to the terminal resize events by immediately redrawing as I resize the terminal? It correctly preserves scrollback buffer in all cases: the span of lines it needs to modify are rewritten, while everything above that point is preserved, with no corrupted duplication or deletion of lines in the scrollback. And this works correctly regardless of how I shift the viewport cutoff to be in the middle of the chunk of lines it needs to rewrite.

If you change your program to use 100 and 99 instead of 10 and 9, you will see that when scrolling up past the top of the window, no part of the scrollback is shown. Blank lines are inserted at the top instead. When the program scrolls down again, you will see that the numbered lines are not scrolled back into view; instead, empty lines are inserted at the bottom.

If you let it cycle a few times, then look at your scrollback, you will see the scrollback buffer contents (the lines that were just off the screen originally) are still intact if you scroll back far enough. What follows afterward probably depends on your specific terminal emulator and its decisions about whether lines that scroll off the top of the screen due to CSI D (SCROLL_DOWN) are added to the scrollback buffer or not.

Maybe Claude Code has a way to change the scrollback buffer itself (which would be, imo, a bug in the terminal emulator), but if so, it's not using CSI M and CSI D to do it. I think it's more likely that it knows how to redraw its own content.

I see what you see in regards to my script. And yet we also agree that CC is successfully erasing the last X lines of the screen - extending up past the viewport - and rewriting them all, effectively rewriting new contents into the scrollback buffer.

I suspect this is why we see the flickering: because the authors of Ink understand that, to achieve this effect correctly across terminals, they must accept this flicker. They must issue ANSI commands that erase the last X lines of output, even if X > viewport height, and then rewrite them all. I suspect that terminal emulators respond to these ANSI commands by removing all of those lines from the viewport / scrollback, then writing new lines into the viewport / scrollback.

The terminal emulator must decide, based on where the user has positioned the scrollbar, if the user's intent is to:
a) follow the bottom of the buffer, following all new output, or
b) remain positioned at any fixed point in the scrollback, allowing new output to appear at the bottom off-screen

This gets messy when the "fixed point" is somewhere in the middle of the block of X lines being rewritten. Mid-rewrite, those lines are all gone. Where is the terminal supposed to position the scrollbar?

Linking related tickets:

https://github.com/vadimdemedes/ink/issues/809
https://github.com/anthropics/claude-code/issues/1913
https://github.com/anthropics/claude-code/issues/769

EDIT: added commentary about how terminal emulators might choose to position the scrollbar based on user intent

And yet we also agree that CC is successfully erasing the last X lines of the screen - extending up past the viewport - and rewriting them all, effectively rewriting new contents into the scrollback buffer.

No, I don't see that at all. I only see lines being appended to the scrollback buffer. Perhaps lines might be erased from the scrollback buffer if you resize your terminal to be larger, in which case some lines have to be brought back out of the scrollback buffer and placed on screen, but in normal Claude Code usage terminals aren't being resized.

But someone did a full investigation and writeup of the problem on that last ticket you linked: https://github.com/anthropics/claude-code/issues/769#issuecomment-3482981776 . Good find! "Ink regenerates the complete output on every React state change" would certainly do it.

Figured it out.

Here's how Ink erases when it needs to rewrite more lines of output than viewport height: (needs to rewrite a portion of scrollback)

https://github.com/vadimdemedes/ink/blob/25a47f92dd8e9fd704ce01f33e2b06ea4a401c70/src/ink.tsx#L251-L259

ansi-escapes' implementation of eraseTerminal: https://github.com/sindresorhus/ansi-escapes/blob/6db12c839dafc906cbceda299026d8e78e501478/base.js#L130

Docs: https://www.real-world-systems.com/docs/ANSIcode.html

It erases the entire scrollback -- including any scrollback from before you launched CC -- and rewrites the entire CC chatlog, which jives with people's observations that it sometimes jumps to the very top of the chat history: it's not trying to erase the last X lines, it's erasing everything, then re-emitting everything from memory. It needs to do this any time a moving/changing part of its UI is _anywhere_ above the top of the viewport.

Maybe that's why I'm not seeing that behavior; I'm using iTerm2, configured not to allow erasing the entire scrollback with 3J.

Okay, so maybe you all can help me then. I am running an Ubuntu server on AWS and I am connecting to the console through the browser. What's a better solution? AWS keeps timing me out, too, which is SUPER annoying if in the middle of a long session. The weird thing is that I can see that Claude is still working, so at least I can watch until it's done before I refresh and log back in.

But, is there a better way to connect to my UBUNTU server on AWS from a windows laptop? Putty or something? LOL. Anything's gotta be better than the console interface on the web. Hopefully it'll fix the issue with the bouncing, too. I see @thepaul states he uses iTerm2, but that sounds like a mac product.

It's just weird that it will even pull back in old context, even after using /clear to clear the context window. What you all are describing sounds accurate, but if that's the case, then clearly CC doesn't remove the old context from the current session's memory. That might also explain why, after very long sessions, even after clearing, my AWS terminal gets extremely slow. Like I will type and have to wait a long time for what I typed to finish showing in the terminal.

So, maybe using some other terminal might fix all of that.

Every claude code user that I know is affected by this, I have to deal with this everyday and it's been going on for months. Can someone at Anthropic takes this seriously? We are all paying customers ffs

I'm using ConEmu and every few minutes, I need to stand up and give my terminal 2-5 minutes to scroll alllllllll the way to the bottom from scratch, it's totally locked up and unresponsive.

I understand that maybe ANSI scrolling stuff is hard. But can we _please_ get just a CLI option in the meantime that will trim to, like, the most recent 2-4 turns? Or cut this gordian knot some other simple way and make the product usable while you develop a robust solution? CC is otherwise incredible!

maybe even a simple command/key to clear the console within the cli?

(BTW, I see this on Windows 11 via conemu using git bash. Broader than platform:macos)

OAI Codex doesn't have this issue so... skill issue not impossible

please fix

&lt;offtopic&gt;@jlopela if you already have a decent terminal installed, just use ssh to your vm. If not, PuTTY is high quality software. https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html &lt;/offtopic&gt;

I finally got Putty working, and it doesn't bounce at all, plus it's as smooth as butter when I type or backspace. Took forever because i kept getting errors with the certificate. I removed the space from the name of the .pem file and then it worked. Not sure if that was what fixed it, or if I accidentally fixed it lol. But, it works with putty, no bouncing. 10/10 much more enjoyable experience. I actually have two different putty windows open at once, each one running claude working on a different app.

This issue really needs to be fixed - it’s a huge productivity killer. Sometimes you just sit minutes in front of an endlessly scrolling terminal, waiting for the right moment to hit Enter so the agent continues and the flickering finally stops.

💯 agree, that this old bug I a productivity killer! I’m unable to scroll
back when subagents are running, and by the time the session completes I
entirely lost context.
This inhibits my ability to follow and course correct my session :/

On Fri, Nov 7, 2025 at 5:12 AM Andreas Donig @.***>
wrote:

adonig left a comment (anthropics/claude-code#826) <https://github.com/anthropics/claude-code/issues/826#issuecomment-3502457226> This issue really needs to be fixed - it’s a huge productivity killer. Sometimes you just sit minutes in front of an endlessly scrolling terminal, waiting for the right moment to hit Enter so the agent continues and the flickering finally stops. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/826#issuecomment-3502457226>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAABTCMP5KVAKQCTCIWLI2D33SLCXAVCNFSM6AAAAAB3O2S5FKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKMBSGQ2TOMRSGY> . You are receiving this because you are subscribed to this thread.Message ID: @.***>

@cspotcode

I think your observations align with mine. I'm developing a xterm.js based terminal multiplexer with node-pty. When the content becomes too big for the viewport (long conversation) and especially when using subagents or tasks, CC basically becomes unusable until it stops.

Digging further, I noticed that sometimes the whole conversation (including the logo at the start) gets sent which I suppose is meant as a redraw (maybe because of agent output). Not sure about that. Anyway, I can clearly see that DEC2026 mode is entered.

Trace of events:

• \x1b[?2026h DECSET 2026. Enter “synchronized updates” mode
• \x1b[3J Erase scrollback buffer
• \x1b[2J Erase the entire visible screen
• \x1b[H CUP, move cursor to top-left
• full conversation including the pig from the start
• \x1b[?2026l DECRST 2026. Exit synchronized updates

When that is sent to xterm.js the jumps occur.

Also related:

https://github.com/contour-terminal/vt-extensions/blob/master/synchronized-output.md
https://github.com/xtermjs/xterm.js/issues/3375

EDIT:
My shot at mitigating the issue with xterm.js.

The unfortunate thing is, this happens because terminal emulators don't allow scrolling the cursor up past the top of the viewport. If, theoretically, a terminal emulator did allow this, then TUIs could move the cursor past the top of the viewport and modify those lines. That would avoid the flicker.

Win32.Console.SetConsoleCursorPosition() supports coordinates anywhere within the buffer, scrollback or visible viewport -- which allows TUIs to render large, scrollable UIs without these limitations. ...but it's not cross-platform.

I briefly investigated running TUIs within a terminal emulator that is hundreds of lines tall -- say, $ROWS == 500 -- only showing the bottom X lines on my physical screen. I tried to accomplish this with tmux or screen. This would not work for something like vim, which is built around the assumption that it can fill the screen and that the end-user can see from top to bottom. But this would work for something like Claude, which never pins anything to the top of the screen; it is only concerned with rendering and re-rendering the last Y lines of the console, where Y is however many lines are populated by moving UI elements.

@mdc-git

Digging further, I noticed that sometimes the whole conversation (including the logo at the start) gets sent which I suppose is meant as a redraw

This happens when and only when the underlying TUI library, Ink, realizes it must modify lines above the viewport. It must modify X lines of output, where viewport height is H, and X > H. If X <= H, this behavior is not triggered.

Put another way, resizing your terminal viewport to be large enough to contain all moving output will avoid this flicker, because X <= H.

@cspotcode

Valid point. To be honest, I haven't bothered looking into Ink. Just sharing my observations. I'm trying to mitigate the visual distortion inside xterm.js. I can't do anything on the CC side, and unfortunately, I can't seem to achieve an _infinite_ viewport practically. I can repeatedly reproduce the issue by spawning parallel agents, even during short/medium sized conversations. Quite soon as they are off the visible area, it _feels_ like they are all battling for scrollbacks and scrollback buffer updates at once. Another person posted a video in this thread:

https://github.com/anthropics/claude-code/issues/826#issuecomment-3218224958.
Screen.Recording.2025-08-24.at.11.33.04.AM.mov.

It looks familiar. xterm.js is also included in the VSCode terminal. This happens to me as well with the integrated terminal. Apparently, other terminals do not show the same behavior, at least in different setups. I'm just wondering if the missing DEC2026 implementation is the culprit in the case of xterm.js.

+1
claude code 2.0.37
macos, intellij

@bcherny @catherinewu are you listening?

happening to me too in integrated terminal in IDE (Cursor). Please fix as it makes me want to switch to Cursor chat :(

This is affecting Linux 100% (I'm in Clion IDE-wise) -- label for that platform should also be added, @chrislloyd

https://github.com/user-attachments/assets/68506af4-e101-4916-ac7e-ff779ac3469b

Also, it would seem this is the original issue, not the duplicate (there's a "duplicate" label), unless I'm missing something

This is very annoying, happening on Windows 11, using the Cursor with PowerShell, then Claude Code inside it

7-month-old issue, common guys

This is mind boggling. They have the most powerful ai in existence - you'd think they'd just vibe code a PTY library.... in a day.

Having this consistently in on Linux when using Plan agent. The pattern seems to be when a response is "too long".

There's a partial workaround for now is to use Claude code extension interface instead of the terminal, but hopefully can be fixed for everyone soon.

Here's Claude's initial hypothesis from log file analysis (I know, ironic).

The INT3 trap + fileWatcher crashes when rendering long terminal output suggests:

Primary Suspect: Terminal Renderer Overflow

When Claude outputs long text:

1. VS Code's terminal renderer tries to process massive amounts of text
2. The ptyhost process (pseudo-terminal host) gets overwhelmed
3. FileWatcher crashes because VS Code is force-killing processes to recover
4. INT3 trap fires when internal buffer limits/assertions are hit

Why FileWatcher Dies

The fileWatcher crashes with code 15 (SIGTERM) are likely VS Code performing emergency cleanup when the terminal renderer hits critical errors. It's killing child processes to prevent total lockup.

"partial workaround for now is to use Claude code extension interface instead of the terminal"

I wonder if that's what they are saying internally (or thinking).

Can you please fix the terminal instead of using this to push everyone into your $1000 credit digital ghetto that no one wants to use.

There's a partial workaround for now is to use Claude code extension interface instead of the terminal, but hopefully can be fixed for everyone soon.

@eon-dev1 Do you mind clarifying, please, kind sir? I'm using the Claude Code extension and I'm running into that flashy problem from the up-and-down scrolling. Is there something I'm missing? A configuration option? Or are you referring to a different extension? Or am I positing about a totally different bug altogether (see the video I share in my first post 3 posts above yours)?

[EDIT:] I guess you were referring to the VS Code version of the extension?

> There's a partial workaround for now is to use Claude code extension interface instead of the terminal, but hopefully can be fixed for everyone soon. @eon-dev1 Do you mind clarifying, please, kind sir? I'm using the Claude Code extension and I'm running into that flashy problem from the up-and-down scrolling. Is there something I'm missing? A configuration option? Or are you referring to a different extension? Or am I positing about a totally different bug altogether (see the video I share in my first post 3 posts above yours)? [EDIT:] I guess you were referring to the VS Code version of the extension?

Referring to this one, yes in VS code

<img width="804" height="694" alt="Image" src="https://github.com/user-attachments/assets/184710be-76e8-48a7-b275-5fb2096d77b0" />

In the meantime Gemini boasting about their flicker free terminal UX

Found this - https://opencode.ai

Never would have tried it but going to this weekend since this trash is never getting fixed.

And this one - https://block.github.io/goose/docs/getting-started/providers/

And this - https://aider.chat/

Wow look at all these alternatives that don't make me waste half my life scrolling through the terminal!

I had the same issue and after i set in my Terminal Profile settings Limit number of rows to : 10.000 this didn't happen again.

This could be fix probably for each OS to adjust scrollback size

It was set before to available memory and my guess it would be that system terminal size scrollback exceeds the memory which can be handled by node.js .

Terminal: Apple_Terminal
Shell: /bin/zsh
ProductName: macOS
ProductVersion: 15.5
BuildVersion: 24F74
2.0.42 (Claude Code)

I've had scrollback on VSCode on 10000 already and I most certainly still have the problem.

I used it with scrollback limit and it was working ok without flickering for 2-3 hours. Then i took it into plan mode and after three messages it started to flicker.

I am pretty sure now the plan itself overrides the scrollback and is causing this

Someone mentioned it was when Claude updates the to do list which explains the planning mode triggering.

Common problem when using claude inside claude-code.el in Emacs. I actually figured it was an Emacs integration problem, but apparently not!

This is ridiculous.
I am dealing with this problem everyday for 3-4 months now.
It has wasted well over a dozen of hours for me, probably hundreds of thousands of hours for all people using it in total.
So much wasted potential.
It just takes all the magic away and turns it into frustration.
How can you not feel ashamed of not fixing such a basic problem?

Still meet that bug. Hopefully there is a fix or any document to guild how to solve it manually

Big far the biggest most critical claude code issue. I assume it's already getting prioritized, but it should be prioritized a lot more by Anthropic. Please Anthropic

I am trying OpenAI Codex now, it has more stars than this has 900 issues only.

this is the worst part of the claude code cli

Actually, what works for me is just resizing the window with CMD + - several times and then going back to CMD + + once it stops flickering.
I am using Ghostty terminal with claude-code inside a tmux session on MacOS.

Actually, what works for me is just resizing the window with CMD + - several times and then going back to CMD + + once it stops flickering. I am using Ghostty terminal with claude-code inside a tmux session on MacOS.

Thanks this does help a lot.

I still like Claude Code the best, but I think this should be a high priority because

1. Not only does it cause the scrolling, but that often causes all of my VS code windows to crash, which is more than just mildly inconvenient.

1. This could probably cause a seizure. If video games could cause one, then this probably could.

Hard to believe @claude cannot fix this issue. The only workaround I found is to play loud dubstep to it.

Please fix this, this happens every time and is really annoying.

@bcherny @ThariqS @dhollman

It's even funnier when claude code launches another claude code and they both have the same bug. It doesn't just yo yo and scroll up etc, it also goes insane every character you type - I've never seen anything quite like it 😆

I'm back to waste some of your time because this bug wastes so much of mine. I love you as a company and your products but will still laugh at all of you while eating popcorn if one of the other model companies destroys you because I hate this bug so much.

I agree with @huntario. well said!!!

I dont care about this bug anymore... Gemini CLI with 3 pro preview model just killed claude code. When code wiki will be available in CLI tool it will be like control headshot for sonnet.

I care about this issue but I'm tired of getting spammed by people who don't understand how to use a bug tracking system. For the love of god, stop leaving useless comments. If you want this issue to get fixed, click "subscribe" and DON'T LEAVE A COMMENT.

Anthropic already has enough information to reproduce and fix this issue. Any comment you leave at this point is just spamming everyone else. Please stop.

@cowwoc The issue is --> We are all developers here and we see there was a fix already --> https://github.com/vadimdemedes/ink/pull/764

The strange folks which maintain this library decided not implement such fix, and the ones from Google did actually fixed it -->

https://github.com/google-gemini/gemini-cli/issues/7016
https://github.com/google-gemini/gemini-cli/issues/7019

They are reading this thread for sure since it is the oldest known problem, people are spamming here because they want to give up from their CLI end users, and would like them either to claude code web or the pure API.

@cowwoc No! You're not in charge and any rage generated around this is a good thing so thanks!

I object that you object that people object about people objecting.
Fairly sure someone will now find my own comment objectionable.
😂😂😂

I found this issue as same.

I'm literally going to have to stop using Claude because of this issue. The flickering is unbearable. Gemini took the fix mentioned, let's go Claude. Also, platform:linux @chrislloyd

It's unfortunate the Anthropic team didn't manage to fix this, I'm still rooting for them but given we now have the alternative, I cancelled my MAX plan and switched to Antigravity IDE, their console doesn't jump around and for my usecase it seems like their new model holds its own.

I wish Anthropic didn't take that "web claude code UI" route :( and instead focused on building a proper solution for devs.

And recently it started happening even more often. It becomes very frustrating and I'm getting nervous when it starts flickering. I'm also thinking to switch to gemini or codex

At least their engineers should update us about the progress if they implemented or working on this bug. @chrislloyd @DAddYE @katylava @stewarthaines @enricoros

I've tried getting a hold of Claude team members on the Discord, to ask about this issue.
But I got put in timeout for 24 hours for tagging the team.

So IMO the team/Anthropic doesn't give a **** about this issue and us as users.
Spend your money where you're valued is my best advice.

Every single complaint you guys have sends an email and a notification out to everyone who has commented btw

For anyone using VSCode/VSCodium with the Claude extension: a workable temporary fix is to use the Tab interface that the extension provides. It feels a bit clumsy and often ends up in odd places in the UI, and I’m not sure why it isn’t placed in the dedicated sidebar instead, but at least it avoids the constant terminal flickering and freezes (and the occasional full IDE hang).

<img width="980" height="1416" alt="Image" src="https://github.com/user-attachments/assets/5a57368a-50b5-4aad-b0f3-5071896674ad" />

7+ months this issue has existed in some form.
Shocking.

Terminal Scrolling Bug - The 7-Month Nightmare

218 comments. 477 reactions. Still open since April.

This isn't a bug - it's a rendering architecture problem.

Root Cause (Actual Technical Issue)

Claude Code redraws the entire terminal buffer every time the status line updates. On long sessions (5+ pages of history), this causes:

1. Screen "flashes" to top
2. Immediately jumps back down
3. Creates strobe effect
4. Makes the tool physically painful to use

Why it happens:

// Current (broken) implementation:
function updateStatusLine(newStatus: string) {
  clearScreen();  // ← REDRAWS EVERYTHING
  redrawAllHistory();
  redrawStatusLine(newStatus);
  scrollToBottom();
}

The clearScreen() + full redraw causes the viewport to jump to top momentarily.

Proper Fix (For Anthropic Team)

Use ANSI escape codes to update ONLY the status line:

// Correct implementation:
function updateStatusLine(newStatus: string) {
  // Save cursor position
  process.stdout.write('\x1b[s');
  
  // Move to bottom (status line position)
  const rows = process.stdout.rows;
  process.stdout.write(`\x1b[${rows};0H`);
  
  // Clear just this line
  process.stdout.write('\x1b[2K');
  
  // Write new status
  process.stdout.write(newStatus);
  
  // Restore cursor position
  process.stdout.write('\x1b[u');
}

This updates the status line without touching scroll position.

Workaround (For Users)

Option 1: Use tmux to "anchor" scroll

# Start tmux session
tmux new -s claude

# Inside tmux, run claude
claude

# Now scrolling is handled by tmux, not Claude's TUI
# Tmux won't jump around during redraws

Option 2: Terminal with better rendering

Some terminals handle full-buffer redraws better:

• Kitty - GPU-accelerated, handles redraws smoothly
• Alacritty - Fast rendering, less flashing
• WezTerm - Good buffer management

Avoid:

• iTerm2 (known to flash with full redraws)
• Standard Terminal.app (same issue)

Diagnostic: Confirm It's This Bug

# Start Claude Code
claude

# Have a long conversation (50+ messages)
# Scroll up manually
# Watch if screen "flashes" during status updates

# If it jumps to top then back = this bug
# If it stays still = different issue

Why This Is Hard To Fix

The underlying TUI library (likely Ink or similar React-for-terminal) is designed to redraw everything on state changes. Fixing this requires:

1. Switch to raw terminal control (no TUI framework)
2. Implement incremental rendering
3. Manage scroll state manually

Estimated engineering effort: 2-3 weeks (major refactor)

Temporary Relief

If scrolling is unbearable, use headless mode for long sessions:

# Instead of interactive:
claude -p "your prompt here" > output.txt

# Then read output:
cat output.txt

Not ideal, but avoids the strobe effect.

Feature Request Alternative

Instead of fixing the TUI, add a "web UI mode":

claude --web
# Opens browser at localhost:3000
# Full conversation UI with proper scrolling
# No terminal rendering issues

This would sidestep the entire TUI problem.

---

Bottom line: This is a known architectural limitation. The team is aware (assignee: @chrislloyd). Until the TUI rendering is refactored, use tmux or switch terminals.

"This isn't a bug - it's a rendering architecture problem."

Stopped reading here...

This is a proof that developers will not be replaced by any AI soon!

this same bug happens on every AI CLI I use, codex, gemini, claude and opencli

At this point this should not be classified as a bug, but as a health hazard for inducing seizures.

It's probably hard to fix, but also.. we assume Opus 4.5 must be able to fix it.

At this point this should not be classified as a bug, but as a health hazard for inducing seizures. It's probably hard to fix, but also.. we assume Opus 4.5 must be able to fix it.

I died of old age waiting for a fix. So there's that too.

@claude if you agree this is #1 priority, please react with the "👀" emoji.

Option 1: Disable status updates (extreme) Run Claude Code without real-time status This isn't officially supported but can be achieved with terminal config) In ~/.config/claude-code/config.json: { "ui": { "disableStatusLine": true // If this exists } }

@JuanCS-Dev , you need to at least read what ai is suggesting to you before posting publicly :))
even you route does not exist. it's a totally hallucinated advise.

@Vasiliy-Bondarenko true, i was multitasking. My bad. Thanks man!

Anthropic wake up!!! Everyone has been waiting for MONTHS!

Let's just ask antropic employees what terminal they use. I guess they
don't even know about the issue

вс, 30 нояб. 2025 г. в 18:22, bkrescaperaseuse @.***>:

bkrescaperaseuse left a comment (anthropics/claude-code#826) <https://github.com/anthropics/claude-code/issues/826#issuecomment-3592681507> Anthropic wake up!!! Everyone has been waiting for MONTHS! — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/826#issuecomment-3592681507>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BBSVOPR7H4BLU3R6XAYPKH337MDTXAVCNFSM6AAAAAB3O2S5FKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKOJSGY4DCNJQG4> . You are receiving this because you commented.Message ID: @.***>

Let's just ask antropic employees what terminal they use. I guess they don't even know about the issue вс, 30 нояб. 2025 г. в 18:22, bkrescaperaseuse @.***>: […](#)

Probably the biggest evidence yet that Anthropic don't use even it themselves despite how much they claim they do.
The future of development? I think not.

Provided that this is probably not easily fixable for terminals which do not support transactional updates - could one at least provide a switch to completely disable any history rewriting?
Basically saying "I accept that the contents of the scrollback buffer may be wrong, I don't care, NEVER try to fix it by clearing and rewriting"?

If this was open-source I would just patch ink that comes with it but since we only get a full roll-up that is a bit more fiddly...

Provided that this is probably not easily fixable for terminals which do not support transactional updates - could one at least provide a switch to completely disable any history rewriting? Basically saying "I accept that the contents of the scrollback buffer may be wrong, I don't care, NEVER try to fix it by clearing and rewriting"? If this was open-source I would just patch ink that comes with it but since we only get a full roll-up that is a bit more fiddly...

Would be great to get some communication from Anthropic team @catherinewu @bcherny . Please say something. Even "we know" would help!

My workaround that makes this significantly less-annoying (modify for your OS / setup): iTerm2 keybinds: Scroll to top: cmd+up-arrow / Mouse side button (front) Scroll to bottom: cmd+down-arrow / Mouse side button (back)

This is incredibly helpful, even though it doesn't fix the underlying problem. Should have thought if it! Thanks.

If you using claude code (CLI) in bun runtime. About this issue, There will be a chance of encountering this problem being difficult and greatly reduced.

Try claude code on Bun runtime.

@claude fix it smh

Hey everyone! I hope it’s okay to share this here!

I’ve been running into the same scrollback/flicker behavior, so I ended up vibe-coding a small pager-style wrapper for Claude Code. It captures CC’s output into a virtual TERMINAL_WIDTH × TERMINAL_HEIGHT buffer (via xterm.js), updates at a steady rate (60fps), and avoids rendering partial frames.

I’ve been using it as a drop-in replacement inside Windows Terminal and VS Code’s integrated terminal, and so far I haven’t hit the scrollback issue while using it. It also supports some simple Vim-style shortcuts.

If anyone wants to try it or take inspiration from it, it’s on my GitHub profile.
/shameless-plug :-)

Similar is in konsole(fedora 43,kde 6.4) just paste +20 lines of texts and you get scroll top then scroll to bottom,

My temp work around : I got caps lock and F1 bound with keyd to quickly toggle between recent apps to hide this when it happens

Persistent across Terminal (native) and Hyper.js.

Until the fix is ready - here's a workaround:

• expand the terminal window to full screen. The flickering is gone and only happens once in a while.

Persistent across Terminal (native) and Hyper.js.

Hyper.js cannot be set up to work as VSCode’s integrated terminal (native terminal works fine).

Y'all still paying for this?

Even AGI won't be enough to solve this, we all need to wait for ASI.

Very annoying bug.

Seems to have gotten worse lately with async agent usage. Its hard to nail down the trigger but todo list, async agents, and question tool all are high suspects. And as others noted, mostly happens with large sessions. Anyone figure out a decent work-around? A few weeks ago a right-click in putty on the terminal would fix it but that stopped working. I've had terms sit scrolling for 10-15mins at a time lately :(

@chrislloyd any update?

Recently, I was able to partially overcome the problem, but then I messed up the script and did not experiment anymore.
The bottom line is that Claude uploads the whole story, all the dialogue branches and other rubbish from his history files. So, most of the time, I don't want to lose just the last context. It's very annoying to explain to Claude where everything is, what we do, and how to use it. At the same time, I no longer care about the history of the session that was a couple of compressions ago. As a result, I made a script that finds the dialog that is currently in use and truncates the entire history to the last compression. In addition, you can remove unnecessary space from the story, which probably won't hurt Claude much to understand the context. Every time my screen started jumping, I would put some point on the old tasks and run a script that: 1) finds our dialog file, clears the old dialog, launches Claude with the -c flag (continued). But as I said, in an attempt to optimize the solution, I just broke the script and it started deleting almost the entire history from me. There are few tokens left to deal with this issue. If someone comes up with the most optimal solution, it will be cool. By the way, you can try to cut out all of Claude's Thoughts in this way, since he then outputs the essence to the user anyway. This will not only partially solve the issue, but also reduce the amount of context (probably if thoughts are part of the context).

`#!/bin/bash

Очистка истории сессии Claude Code

Обрезает до последнего компакта + сжимает длинные тексты

#

Использование:

./clean-session.sh # сжатие до 1000 символов

./clean-session.sh 500 # сжатие до 500 символов

./clean-session.sh 2000 ID # сжатие до 2000, конкретная сессия

PROJECTS_DIR=~/.claude/projects
MAX_LENGTH="${1:-1000}"

Если первый аргумент - не число, это ID сессии

if ! [[ "$1" =~ ^[0-9]+$ ]] && [ -n "$1" ]; then
MAX_LENGTH=1000
SESSION_ARG="$1"
else
SESSION_ARG="$2"
fi

Определение файла сессии

if [ -z "$SESSION_ARG" ]; then
SESSION_FILE=$(find "$PROJECTS_DIR" -name "*.jsonl" -type f 2>/dev/null | xargs ls -t 2>/dev/null | grep -v '/agent-' | head -1)
elif [ -f "$SESSION_ARG" ]; then
SESSION_FILE="$SESSION_ARG"
else
SESSION_FILE=$(find "$PROJECTS_DIR" -name "${SESSION_ARG}.jsonl" -type f 2>/dev/null | head -1)
fi

if [ -z "$SESSION_FILE" ] || [ ! -f "$SESSION_FILE" ]; then
echo "Файл сессии не найден"
exit 1
fi

SIZE_BEFORE=$(du -h "$SESSION_FILE" | cut -f1)
LINES_BEFORE=$(wc -l < "$SESSION_FILE")
echo "Файл: $SESSION_FILE"
echo "До: $LINES_BEFORE строк, $SIZE_BEFORE"

Найти последний компакт

COMPACT_LINE=$(grep -n '"subtype":"compact_boundary"' "$SESSION_FILE" | tail -1 | cut -d: -f1)

if [ -z "$COMPACT_LINE" ]; then
echo "compact_boundary не найден — нечего чистить"
exit 0
fi

echo "Компакт на строке $COMPACT_LINE, сжатие до $MAX_LENGTH символов"

Бэкап

cp "$SESSION_FILE" "${SESSION_FILE}.bak"

Обрезка + сжатие

tail -n +$COMPACT_LINE "$SESSION_FILE" | jq -c '
def truncate(max):
if type == "string" and length > max then
.[0:max] + "...[обрезано]"
else . end;

def clean:
if type == "string" then
gsub("\\s+"; " ") | gsub("^\\s+|\\s+$"; "")
else . end;

# Удаляем release-notes
if (.message.content? | type == "array") and
(.message.content | any((.text? // "") | test("release-notes|Version [0-9]+\\.[0-9]+"; "i")))
then empty
# Сжимаем контент
elif .message.content then
.message.content |= map(
if type == "object" then
if .text then .text |= (clean | truncate('"$MAX_LENGTH"')) else . end |
if .content and (.content | type) == "string" then
.content |= (clean | truncate('"$MAX_LENGTH"'))
else . end
elif type == "string" then
clean | truncate('"$MAX_LENGTH"')
else . end
)
else . end
' > "${SESSION_FILE}.tmp" 2>/dev/null

if [ -s "${SESSION_FILE}.tmp" ]; then
mv "${SESSION_FILE}.tmp" "$SESSION_FILE"
SIZE_AFTER=$(du -h "$SESSION_FILE" | cut -f1)
LINES_AFTER=$(wc -l < "$SESSION_FILE")
echo "После: $LINES_AFTER строк, $SIZE_AFTER"
echo "Бэкап: ${SESSION_FILE}.bak"
else
echo "Ошибка jq, бэкап сохранён"
rm -f "${SESSION_FILE}.tmp"
exit 1
fi
`
Here's an example script that clears the current chat history (you have to type a message so the chat can be found at the last modified date). But, as I said, the script is broken and currently clears almost the entire history. I'm giving it away as is just so someone can polish it up, as I'm too lazy to do that right now.

this is the most annoying and persistent bug in claude code

Thank you for your patience folks. This is a symptom of scrollback clearing, which we've greatly reduced in v2.0.72 and is documented in #769. You may be interested in an in-depth explanation of the issue and what we did about it. I'm going to close this issue, but feel free to open new issues for specific bugs you encounter.

Still broken on IntelliJ v2.0.76, this shouldn't have been closed.

Better, but would not consider this solved. Issue still occurring on PhpStorm 2025.2.6 w/ Claude Code v0.1.14-beta

no way this is "completed" @chrislloyd its still happening on v2.0.76

codex doesn't do this even a tiny bit so really any flickering is unacceptable

still happens here too.

hi guys sorry we had to roll back our fix for this in 2.0.74 due to some edge cases and wanting to not patch too much over the holidays, but will be bringing it back in the new year

I'm having this as well. Really annoying!

still seems to be an issue

On Pop!_OS COSMIC with v2.0.76 and a custom statusline, experienced the scroll-on-every-keystroke bug. Disabling statusline in settings.json stopped the bug. Re-enabling it did NOT bring the bug back. Suggests some kind of state corruption that gets reset when statusline config is toggled.

If I get more than a screen of output back, or if I do a huge paste, even after a /compact, I get this fairly consistently now when the plan tool is used requesting my approval of the plan. Every keypress is a seizure. I had one very very long session that was literally taking 10-15mins per keystroke. I typed two words and just walked away to see if it would crash or finish. It finished...

Can intellij be configured to use a different terminal - https://ghostty.org/download

https://github.com/anthropics/claude-code/issues/769#issuecomment-3688503436

Someone is going to have a seizure from this.

Someone is going to have a seizure from this.

@chrislloyd Please address this urgently, as it can cause serious medical issues for photosensitive users. It also disrupts the conversation, since the session becomes unusable for some time due to the flickering issue.

@bcherny @chrislloyd can you get an answer from Anthropic for
-what resources are currently allocated to solve this critical situation?
-if issue can be solved or not?
-if a commercial gesture is intended?

So that we can know if we need to switch provider or not, we all have projects and we all do prefer honesty and clear communication.

please i beg u anthropic, no more seizures while im asking claude to fix my many many dockerfiles

+1

+1

I think any of those services should be concerned by the situation
support@anthropic.com
For any technical assistance or general questions.
sales@anthropic.com
For commercial inquiries or partnerships.
privacy@anthropic.com
For questions related to privacy, data access, or data deletion.
disclosure@anthropic.com
To report incorrect, biased, or offensive responses from Claude.

Is something fixed in 2.1.1 released version?

This thing it's happening me on VSCode + Git bash always. It's really annoying.

pleas fix this guys come on

This has been an annoyance for so long that I can't but join the comment section chorus.

Using xfce4-terminal and zsh.

Wouldn't it be neat though if CC was open source and the users could just create PRs about such things? 😜 One time I actually cloned the repo just to realize that oh snap the code's not here.

looks fixed guys, anyone noticed it?

looks fixed guys, anyone noticed it?

I had this happen less than 24h ago. Not sure if we've received updates after that. Will report back here if I can replicate this today.

Edit: yeah, was able to reproduce

for me it got worst with the last version, it hurts my eyes, this is the only thing that keeps me for recommending this tool to my colleagues

for me it got worst with the last version, it hurts my eyes, this is the only thing that keeps me for recommending this tool to my colleagues

IT HURTS MY EYES TOO!

This is killing me... I can't review the code it is doing because it snaps to the top of the window when I focus out. Please fix! Using WSL2 terminal only. No VsCode being used.

for me it got worst with the last version ...

Ya, I feel like I really noticed it in the last version

JetBrains has marked it as fixed from their side in intellij's terminal, not sure when will they release it.
https://youtrack.jetbrains.com/issue/IJPL-204106#focus=Comments-27-13179130.0-0

Still to date this is a big issue. I use Claude Code in windows terminal and it's jumping to the top of the session history all the time. When I use Claude Code via Claude desktop it's good for about 30 minutes and then it becomes intolerably slow and I have to restart Claude Desktop app. How is it that one of the biggest AI tools vendors has the worst useability problems? I don't see this behavior in Gemini CLI.

+1

JetBrains has marked it as fixed from their side in intellij's terminal, not sure when will they release it. https://youtrack.jetbrains.com/issue/IJPL-204106#focus=Comments-27-13179130.0-0

IntelliJ has released a preview build with a fixed terminal that supports synchronized output mode.

Please test this build and share your feedback to them.

Reference: https://youtrack.jetbrains.com/issue/IJPL-204106/Terminal-flickers-when-running-interactive-programs-like-Claude-Code#focus=Comments-27-13182068.0-0

+1

I Switch to opencode for this Problem, but anthropic keep close access for opencode
any response Please??

+1 i still observe the issue in claude code 2.1.7 on my fedora in alacritty

Same problem across all terminals in linux (ubuntu 25), including VS Code. It becomes unusable whenever it stops responding.

https://github.com/user-attachments/assets/6bc38e93-9d8f-4834-ae37-4454f4ee9672

+1

+1. iterm2, macos

@chrislloyd what's taking so long?

+1
In the normal Terminal on macOs and inside a tmux session there is no issue,
but on iTerm2 this problem persists.

This issue must be resolved urgently. I am no longer able to use CC, the issue can be fixed by making the bottom chat fixed and adding a built-in scroll feature like tmux. I migrated to OpenCode + Synthetic because of this issue.

As we can no longer use our Claude Max subscriptions with 3rd party platforms, Claude Code must be fixed and made better to keep up. UX of AI agents is more important than AI quality for me.

The problem disappeared after updating iTerm2 to the latest beta version
(3.6.7 beta 2)

regards

пт, 16 янв. 2026 г. в 09:00, Halil Tezcan KARABULUT <
@.***>:

unitythemaker left a comment (anthropics/claude-code#826) <https://github.com/anthropics/claude-code/issues/826#issuecomment-3758315527> This issue must be resolved urgently. I am no longer able to use CC, the issue can be fixed by making the bottom chat fixed and adding a built-in scroll feature like tmux. I migrated to OpenCode + Synthetic because of this issue. As we can no longer use our Claude Max subscriptions with 3rd party platforms, Claude Code must be fixed and made better to keep up. UX of AI agents is more important than AI quality for me. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/826#issuecomment-3758315527>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BBSVOPW4COTOEBYT4OMES6L4HB46HAVCNFSM6AAAAAB3O2S5FKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTONJYGMYTKNJSG4> . You are receiving this because you commented.Message ID: @.***>

This is a massive issue, VSCode or otherwise

The thrashing was driving me nuts so I wrote a PTY proxy that wraps CC so it behaves more nicely: https://github.com/davidbeesley/claude-chill

Main issue appears to be that CC sends roughly [SYNC START]Text Rendered[SYNC STOP]. All output is wrapped in sync blocks, but about half include a screen clear and cursor reset - those are full redraws where Text Rendered is the whole conversation (94KB avg from one conversation I dumped going up to about 120K tokens - 3.3GB total). The workaround catches those and only sends the last 100 lines. The other half are small incremental updates that pass through unchanged. There's a hotkey to dump the full buffer if you need to scroll up.

Resolved the issue for me (tmux/linux, often over SSH) - no thrashing/strobing or performance problems when conversations get long.

EDIT: Added support for macos

Switching to open code

The problem disappeared after updating iTerm2 to the latest beta version (3.6.7 beta 2) regards пт, 16 янв. 2026 г. в 09:00, Halil Tezcan KARABULUT < @.***>: […](#)

+1

'commit files' or 'restart app' causes claude to scroll for minutes. it's near un-usable.

if you someone use wezterm please use nightly version. latest version is 2024 late version. wezterm nightly + tmux version is less flickering. (not perfect)

forget this. does not work.

Still not fix.

Guys, wtf are you doing, when is this going to be addressed? This is such an annoying issue, even more than the flickering bug.

Please focus on quality control, the bugs are getting out of hand.

I'm using the embedded terminal in VSCode and I haven't had an issue in some time. I use sub agents a lot and that helps, but, I do remember the issue being quite bad after they rolled back the fix end of the year. Right now it's smooth sailing.

Switching to open code

They'll just suspend your account. Cancel your sub and move to another provider.

OC working perfect try it!
Also try oh-my-opencode

The problem disappeared after updating iTerm2 to the latest beta version (3.6.7 beta 2)

updated iTerm, issue persists (takes a couple minutes of usage to show)

Can anyone confirm if this issue exists (in linux/bsd(MacOS)) with the Claude Codes native installer? Meaning... when installed with the native installer, does the new installation have this issue? I was not sure if anything changed other than the installer going from npm to non npm.

Can anyone confirm if this issue exists (in linux/bsd(MacOS)) with the Claude Codes native installer? Meaning... when installed with the native installer, does the new installation have this issue? I was not sure if anything changed other than the installer going from npm to non npm.

yes.

All of versions old/new still have this issue. i can confirm.

IntelliJ is able to resolve this by enabling Implement support for synchronized output mode.
So far, after upgrading to 2025.3.2, I have not encountered this issue.
https://youtrack.jetbrains.com/articles/IDEA-A-2100662610/IntelliJ-IDEA-2025.3.2-253.30387.90-build-Release-Notes

Do other terminals also need to enable this? Has the iTerm beta—which fixed the issue in its beta version—already implemented this support?

The scrolling issue still exists in 2.1.19 - ubuntu- termnitor

Another video recorded in VSCode's Terminal on MacOS using 2.1.20. Same behavior in iTerm.

https://github.com/user-attachments/assets/c1550b47-f4a4-4d5d-b75d-141fe8fcb34b

You can see the issue disappears after output ends/pauses.

I can still reproduce this cross-platform. I still have this in Fedora via Konsole, Warp, kitty, VSCode, tmux, ssh; macOS via iTerm2, kitty, VSCode; Windows via VSCode.

OC working perfect try it! Also try oh-my-opencode

Opencode switched to opentui. Frankly I think their CLI is currently the best. It's also the only one that isn't a fork/clone of whatever was the originator of agentic CLIs. (gemini-cli?)

https://github.com/anomalyco/opentui/

This is pretty obviously triggered by some sort of silent periodic background re-render combined with whatever janky React tui implementation they've decided to use. C'mon, Anthropic, put on the big boy pants, use a different tui, and fix this properly.

I had this bug for a long time too - and still have it. One work around is to use tmux

I had this bug for a long time too - and still have it. One work around is to use tmux

I use tmux + kitty and I have it still, it only happen with long conversations and on plan mode.

I feel like this isn't happening any more...

Still happening on 2.1.45. I've been using tmux recently for teams orchestration and it seems to not happen there.

I use tmux + kitty and this is still happening as of version 2.1.47

They continue to vibe code their client. They cannot or will not fix bugs that have existed for going on 9 months but still have the stones to claim AGI is 6 months away. Hilarious.

Opus is a great model but Anthropics tooling is garbage. With the recent legal threats to OpenCode I've had to move to Codex sadly. I tried Claude Code again in the hope this stuff was fixed, but no. It still eats RAM. It still lags for 5 minutes after it first opens. It still flickers.

If you're going to start doing vendor lock in, at least fix your fucking tools so we can use them.

Environment: macOS Darwin 25.3.0, Ghostty 1.3.0, Claude Code v2.1.74

Still reproducing as of March 2026. Even with Ghostty (native DEC 2026 synchronized output support) + latest Claude Code (differential renderer), the uncontrollable scrolling persists in long sessions.

Reproduction: Start a conversation, accumulate context to ~50%+ capacity. The terminal begins rapid scrolling on every TUI update — scrollbar shoots to the top and back. Scrolling up during Claude's response makes it worse (runaway scroll acceleration). The only workaround is frequent /compact to keep context short, which defeats the purpose of long-context conversations.

Key observation: This is NOT terminal-specific. Ghostty with synchronized output should eliminate rendering flicker, yet the scroll behavior persists — suggesting the root cause is in Claude Code's TUI transcript management, not in terminal rendering capabilities.

Impact: Makes long coding sessions nearly unusable. Have to choose between context depth and UI stability.

I use claude code for a week now and first this doesn't happend, but now (after an upgrade yesterday) I get this bug and it's really annoying. It jumps to the top with every other output. It's really annoying.

@duracell Same here. This has been an open issue for 9 months with 700+ upvotes and 300+ comments — yet no official fix or even an ETA from Anthropic.

The differential renderer they shipped reduced flickering by ~85%, but the core scrolling issue remains. It's architectural: the TUI redraws the entire transcript on every update, which fundamentally doesn't scale with long conversations. No terminal can fix this — I've tested with Ghostty (native DEC 2026 synchronized output), and it still happens.

The only workaround is aggressively using /compact to keep context short, which is a frustrating trade-off.

@anthropics — This is the most upvoted open bug in the repo. Any update on timeline or plan?

Experiencing this on Windows 11 with Windows Terminal + Git Bash (MINGW64).

Environment:

• Claude Code v2.1.74
• Windows Terminal (Git Bash / MINGW64)
• Windows 11

Behavior:
Once the conversation reaches a certain length, new streamed text (Claude's response, tool output, etc.) causes the viewport to jump to the very top of the scrollback buffer and then snap back. This doesn't happen every time ΓÇö it seems more likely to trigger after I've scrolled up to review earlier output or selected text. This makes it difficult to read streaming output or review context during longer sessions.

Notes:

• Does not occur at the start of a session ΓÇö only after significant scrollback has accumulated.
• I don't recall this being an issue in earlier versions, so it may be related to the v2.1.7+ TUI rendering changes mentioned in #18299.
• /compact and /clear temporarily alleviate the issue by reducing scrollback, but it returns as the conversation grows again.

---
This comment was drafted with Claude Code.

For hell, more than one year of bug and no one is abble to fix that !@#$!#%&%$$%@ ??!?!?!??!?!

They tried using CC to fix it but it keeps scrolling up

I am experiencing the same issue on Cursor.

I've been experiencing this since day one and finally dug into the root cause. The scroll-to-top happens because Claude Code triggers full screen redraws (CSI 2J clear-screen inside DEC Mode 2026 sync blocks) when responses get long enough (~400+ lines). The terminal is doing exactly what the application asks — it just happens to reset scroll position.

I built a lightweight proxy that sits between your terminal and Claude Code, intercepts these full-redraw sync blocks, and strips the clear-screen sequence before forwarding. The content still updates correctly but your scroll position stays put.

It's a single Windows exe, MIT licensed, no config needed:
quell claude

GitHub: https://github.com/FurbySoup/quell

Windows only for now since it uses ConPTY. Happy to answer questions about the approach if anyone's interested in the technical details.

That's weird, never have such bad terminal experience with Codex

Hitting this as well, v2.1.76 in iTerm2. It's extremely annoying, please prioritize this issue @ollie-anthropic @anthropic-xabi

The workaround to disable terminfo E3 scrollback clearing seems to stop the scroll reset, but of course results in Claude Code adding a copy of the entire conversation on _every update to the conversation_, quickly filling the terminal buffer to the point of crashing the terminal.

I think there are doing it on purpose -- what is the point of them clearing clearing the context from the history at all? Why do they do that, they are controlling what we see, why not just leave all output in the terminal windows? Same concept with compaction, why remove the previous session data?

Is that you want to limit the amount of information the Engineer can see?

_I say this because there is so much fabrication that I see, clear contradictions, it said something 10 minutes ago then says the exact opposite._

I think the reason it jumps to the top is because they are actively removing data from the top.

The problem hasn't gone away for me but it's very manageable. Yes the screen jumps, but before I would be looking at a terminal that gets locked up for a long period, scrolling up and down like crazy.

If you perhaps are using VS Code, and are on a Windows Remote Desktop connection, changing a setting may help. I was still having a lot of trouble and high CPU usage by VS Code. When I set terminal.integrated.gpuAcceleration to off that went away. The issue still happens but it mostly looks like a screen flicker.

See https://github.com/FurbySoup/quell

Issue officially fixed for me!

A fix for this is available as a Claude Code plugin: https://github.com/anthropics/claude-code/pull/35683

The scroll-fix plugin clamps cursor-up sequences within synchronized output blocks to the viewport height, preventing the terminal from scrolling to the top. Also includes Ctrl+6 freeze toggle for manual scroll control. Works on all platforms and terminals.

A fix is available as a Claude Code plugin: scroll-fix

Install:

/plugin marketplace add cruzlauroiii/claude-code
/plugin install scroll-fix@cruzlauroiii-plugins

Root cause: both Ink renderer AND readline/prompt system emit cursor-up sequences exceeding viewport height. The plugin clamps all cursor-up per write call. Also includes Ctrl+6 freeze toggle.

PR: https://github.com/anthropics/claude-code/pull/35683

@cruzlauroiii i just tested your plugin and i get the exact same behaviour, using via termius (ssh)

Please fix this. It drives me crazy. (iTerm2, zsh, MacOS)

Someone built a solution for this, I hope it works: https://github.com/FurbySoup/quell
if it works, let's motivate the author by giving star :)

Same issue here on VSCode's built in terminal, running in WSL on Windows.

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

This is still an issue and it's making claude almost unusable for me.
I tried using tmux but it still flickers. I tried using Kitty but it's annoying for a different reason - is scrolls down whenever there's new output, so i still can't scroll and look at code. I don't want to resort to using the VSCode extension because i like the terminal better.
Does anyone have a workaround? It can be the most grueling workaround, i'll install anything, do anything, i just want to be able to scroll while it's thinking, and to not experience flickering if i don't scroll.

I released a CLI proxy that fixes most of this (there are upstream Windows Terminal and Claude Code bugs blocking a full fix).
Working on a Tauri terminal solution now which bypasses those issues and has some nice UX features.

This issue is open for almost a year. What are you doing? This is a breaking bug and a lot of pople move away from Claude Code because of 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.

This issue is open for almost a year. What are you doing? This is a breaking bug and a lot of pople move away from Claude Code because of this!?

Evidently, they don't actually care. At all. Despite us paying good money for an expensive service, they think of us as "useless eaters" no doubt.

This is what happens when companies hit too much success, too quickly. Complacency, laziness and greed. I'm just surprised more people with large followers aren't actually speaking about this problem. If I knew any of them, I'd be bringing it to their attention. It's not just this bug, there are many. The flickering terminal bug took them like a year to fix as well.

It has an official catchphrase, it's "f you, I've got mine".

And this sort of thing is exactly why I'll never speak highly of Anthropic as a company or of its culture, and why no one else should either. They demonstrate time and time again they do not care at all about their paying customers (short of the few companies that give them millions, perhaps - but even within those I'm sure there are plenty of developers who are using Claude Code and are completely frustrated with their experience as well).

The other wild thing is that these are unprecedented times. Anthropic looks at us as a dying breed with the ambition of replacing us all. Why throw crumbs to the peasants? We're just being used as a bootstrapping mechanism for the inevitable decommissioning.

I hope you all realize what the stakes are here. Don't be deceived.

i tried using claude code inside zellij, and somehow the scrolling issue is not happening anymore.

This issue does not occur in ~~Gemini~~ or Codex. (Gemini has same problem)
You can use them instead until this is resolved.

It's a problem caused by a wrong escape sequence Claude Code introduced
during the session. I managed to mitigate it in my TUICommander, but there
are multiple causes, so I'm sure they don't know where to start. I lost
days trying to understand the wrong escape sequence without luck. Really
annoying.

Il giorno gio 26 mar 2026 alle 00:33 Sangbeom Han @.***>
ha scritto:

uronly14me left a comment (anthropics/claude-code#826) <https://github.com/anthropics/claude-code/issues/826#issuecomment-4130501789> This issue does not occur in Gemini or Codex. You can use them instead. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/826?email_source=notifications&email_token=AADRNCKEYCZZOEJW75CBPWT4SRUDNA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMJTGA2TAMJXHA42M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4130501789>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADRNCN3QR3BAADR2SHU5334SRUDNAVCNFSM6AAAAAB3O2S5FKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCMZQGUYDCNZYHE> . You are receiving this because you commented.Message ID: @.***>

This scroll-jumping issue worsens as conversation length increases. While the root fix needs to come from Anthropic's TUI rendering, here are practical mitigations:
Workaround 1 — Compact regularly:

/compact

The scrolling issue is proportional to conversation length. Compacting reduces the rendered history and significantly reduces the jumping. Try compacting every 30-50 messages rather than waiting for auto-compact.
Workaround 2 — Start new sessions for new tasks:

claude --resume  # Lists recent sessions
claude

Rather than running one long session, start new sessions for each distinct task. This keeps the rendered history short.
Workaround 3 — Use tmux to isolate scrollback:

tmux new-session -s claude 'claude'

tmux maintains its own viewport and scrollback buffer. Some users report that the scroll jumping is less severe inside tmux because tmux handles the terminal state differently.
Workaround 4 — Terminal-specific settings:

• iTerm2: Preferences → Profiles → Terminal → set "Scrollback lines" to a smaller value (e.g., 1000). A shorter scrollback buffer may reduce the severity.
• Ghostty: Some users report less scrolling issues compared to iTerm2.
• VS Code terminal: Using the integrated terminal sometimes exhibits this less than standalone terminals.

Workaround 5 — Use headless mode for long-running tasks:

claude -p "Your long prompt here" > output.md

Headless/pipe mode doesn't render the TUI, so scrolling issues don't apply. Useful for batch operations.
This is one of the most-reported issues (795 reactions), so it's likely high priority for Anthropic's team. The workarounds above help manage it until a fix ships.

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.

This still happens to me daily. Using latest Gemini CLI and latest Warp in WSL. Incredibly frustrating. If you resize the window once this behavior happens then the entire thing goes blank, often requiring me to dump the terminal entirely.

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

Analysis

This is a long-standing (April 2025) terminal scrolling bug affecting Claude Code, Codex, and other TUI tools that use DEC 2026 synchronized update sequences during streaming.

Root cause

Claude Code's TUI (built on ink, a React terminal renderer) emits ED2 (\x1b[2J — "Erase Display") inside a DEC 2026 synchronized update block. The ED2 sequence resets the terminal's viewportY to 0, which yanks the scroll position to the top. On the next sync unlock, the viewport snaps back to the bottom — causing the "stroboscope" flicker.

This is a confirmed xterm.js bug: xtermjs/xterm.js#5801. It affects VS Code, Cursor, and any other IDE using xterm.js < v6.

Fixes (upstream)

1. ink (Claude Code's TUI framework): Clamp cursor-up sequences to the viewport height instead of emitting absolute ED2. See vadimdemedes/ink#934.

1. xterm.js (VS Code, Cursor): Upgrade to v6+ which properly handles DEC 2026 synchronized output without viewportY reset.

1. Alternative terminals: Pane has implemented a fix at the terminal level that handles this correctly.

Workarounds

• Use a native terminal app (macOS Terminal.app, iTerm2, Kitty, Ghostty) instead of VS Code/Cursor's integrated terminal — these don't use xterm.js and are unaffected
• In VS Code, set "terminal.integrated.gpuAcceleration": "off" or "canvas" to mitigate
• In Cursor, the same setting applies
• Keep the terminal scrolled to the very bottom (don't scroll up mid-stream) — the auto-scroll only triggers when you're not at the bottom

I thought coding was a solved problem. Why not squash all the bugs :)