Terminal Flickering

Thanks for the report. What terminal is that?

I've been having the same issue for weeks. It's the Windows terminal (win11 for me, WSL2 Ubuntu).

I've noticed it tends to happen when the terminal history gets quite long, so I'm not sure if that's related or not? Restarting Claude doesn't fix it, I have to either open a new terminal or clear the terminal first and then re-open.

Here's what I have for settings:

HISTCONTROL=ignoreboth
HISTSIZE=10000
HISTFILESIZE=10000

Does running /clear in claude resolve it?

Use !clear periodically to clear the bash history, this would stop the flickering from happening. This would not clear the context (unlike /clear)

It's WSL2 on Windows

Its happening when the whole thread gets long.

1. In Windows - Open Windows Terminal
2. Press Ctrl + , to open graphical settings.
3. At the bottom left, click “Open JSON file” (or the {} icon).

!Image

1. In the opened settings.json, locate the "profiles" section and add: "compatibility.enableUnfocusedAcrylic": false

e.g.
"profiles": {
"defaults": {
"compatibility.enableUnfocusedAcrylic": false
},

1. Save the file and close it
2. Close all open Terminal windows completely
3. Reopen Windows Terminal.

The flickering should now be gone when using WSL or other profiles.

Same for me, made a comment in a previous issue and added a video, see https://github.com/anthropics/claude-code/issues/392#issuecomment-2970234466

It happens to me on all terminals. I'm on iTerm2 Mac mostly

I feel like the issue is getting worse all of a sudden, especially navigation around the prompt input field. They seem somewhat related, because they seem to happen around the same times (i.e. when I notice navigation issues, I also notice flickering issues around the same time). All seem to be tied to the size of outputs, inputs, or overall session.

happens in ubuntu 24.04 terminal also.... this happens when the information overflows the current terminal viewport..... specially when using multiple parallel agents, this will happen... maybe on a bigger 4k monitor it doesn't but on 1080p it sure does.... just a guess

I am also facing this same problem in mac warp terminal. solve this asap!

I think we need a command to clear the chat history without it deleting the context.

I think we need a command to clear the chat history without it deleting the context.

I think this is almost there with /compact. The command just needs a slight extension.

Same issue for me. This is making claude code almost unusable. I am using wsl2 with arch linux.

Hi, maybe issue is related to term height? see https://github.com/vadimdemedes/ink/issues/359
and can you check possible fix in https://github.com/oclif/multi-stage-output/pull/11/files

xterm, flickering is annoying

Terminal Flickering is giving me headaches, please resolves it, I can not use it after certain time.

Warning: This might give people siezure who are susceptible to it also.

https://www.epilepsy.com/what-is-epilepsy/seizure-triggers/photosensitivity

I resolved this by clicking escape, and then message shows up in command field, and then i just press enter

This is also occurring for me in a variety of terminals across operating systems, as @SahilDahiya mentioned, this is an issue for those who have epilepsy. While not a personal issue for me, it is something to consider

I'd actually just like to add now that it affects my ability to type, as when it flickers, it seems to not register typing

Yes, super bad for me, I'm gonna have a seizure or something. Anthropic, unleash Claude Code to fix it itself. Terminal window and text and the whole thing flashing up and down out of control when typing and context/history is large. On MacOS, zsh, running in Cursor/VScode native terminal.

Lets see if they have their own github action running,

@claude jump in, read all of these comments, and fix this bug/bugs, these users are very important to us and we need to get the terminal experience 100% for them asap

@GustyCube I thought claude code was closed source - how are you going to fix this yourself...?

From what I can tell, moving to incremental rendering in Ink (the cli rendering lib claude code uses) might help (assuming improve ink, and then somebody who works on CC upgrades the version of Ink that CC uses). There is a work in progress over here for those that want to dig in -> https://github.com/vadimdemedes/ink/pull/708

@ashwin-ant Are you guys aware of this bug? My experience is that as soon as the terminal starts flickering its just a matter of time till it crashs, especially in VSCode and similar IDEs

In case someone is looking for a workaround, for some reason enabling "Maximize throughput at the cost of higher latency" option in iTerm2 (latest beta, not sure if that matters) stopped flickering on it's tracks, as soon as I clicked the checkbox. Have not seen any flickering all day today.

<!-- Uploading "Screenshot 2025-08-14 at 3.53.54 AM.png"... —>

I see this flickering really bad when Claude Code has multiple sub-agents running at once. It's as though each sub-agent is trying to make TUI updates at once and the TUI goes crazy with flickering. Once the multiple agents have finished and I am back to a single agent (or they've all finished), the flickering completely stops.

When I continue the session with a new prompt that spawns multiple agents, the flickering comes back immediately.

I have also seen this happen with a lot of subagents and a long thread. CMD+K cleared the output temporarily but then the flickering started happening again. Eventually, that lead to a memory crash related to a GC issue.

Yeah, this is super bad, and happens across different terminals for me in different environments and different window sizes. I've actually switched to using new Codex VSCode extension now as this is unusable to me. Its good! Anthropic pretty please fix pretty please.

it's crazy that this has been an issue for 2 months or so and still hasn't been fixed 😂

How to solve it on cursor (WSL2, windows)

Yeah, I'm having the same issue running subagents and having an insanely flickering screen. If anyone finds a workaround, let me know!

I have the same issue, IntelliJ Idea, just one agent running, Manjaro Linux. Even if I clear buffer the situation is impossible. TO solve it and do a favour to my eyes, I might need to go up, no to show the latest line. But as noted, this might make it impossible to type.

I have the feeling that it has to do with esc codes that handle cursor movement? \n character? at any case it is when it updates stuff not at the current cursor, but adds data just above. Like , it doesn't handle well updating stuff above.

This happens across terminals on macos (iterm2 & wezterm) for me and even when there are no subagents running. Frustratingly, it's just as bad in the new native bin claude code v2.0.0.

Still happening.

1. In Windows - Open Windows Terminal 2. Press Ctrl + , to open graphical settings. 3. At the bottom left, click “Open JSON file” (or the {} icon). !Image 4. In the opened settings.json, locate the "profiles" section and add: "compatibility.enableUnfocusedAcrylic": false e.g. "profiles": { "defaults": { "compatibility.enableUnfocusedAcrylic": false }, 5. Save the file and close it 6. Close all open Terminal windows completely 7. Reopen Windows Terminal. The flickering should now be gone when using WSL or other profiles.

seems it's working ... thank you... I did it with 'PowerShell-7.5.3-win-arm64' + terminal app for windows

@quantum-vector-io Per https://learn.microsoft.com/en-us/windows/terminal/customize-settings/interaction the default value is already false...

I am experiencing this using with kitty/neovim, it seems to me something with the scrollback buffer and with how Ink and/or Claude Code handles it's fullscreen rendering. This seems promising: https://github.com/vadimdemedes/ink/issues/263#issuecomment-600927688

Unfortunately, without access to source there's little we can do but poke around and guess.

indeed @cowwoc you right

in vs code terminal it's almost in the beginning working like that... especially with long context inserted... but, I notice it kind of more stable in terminal + powerShell 7... and yes it not related to "compatibility.enableUnfocusedAcrylic": false

It's happening to me on Intellij Terminal (MacOS Apple Silicon)

It happens to me on Windows and Linux.
In Windows, it happens on Git Bash and CMD.

iTerm2 happens when you have a short (vertical) terminal

Also happening quite often in IntelliJ Terminal (mac)

Yep, happening loads to me in intellij terminal. Ubuntu 22.04.

It's pretty infuriating as you have no oversight of what the agent is doing.

Increasing the height of the terminal sometimes works, but that's not a practical solution in a lot cases.

I abandoned Claude Code since a few months and use opencode https://opencode.ai/ instead which is far better and stable for me, at least on macOS, can't tell about Linux and windows. Even working with Claude max plan.

Pretty sure this is because Claude Code is dumping out massive quantities of data to the terminal as part of whatever it's doing for rendering its history/scrollback. I encountered this, but I'm connected over SSH to a remote server where I'm running Claude Code, and when this happens, the network throughput from the server is crazy high, and it can take a very long time before all the data is sent back to my terminal over SSH.

It's as though Claude Code is replaying the entire history back out to the terminal many, many times redundantly. Sort of like re-rendering the entire scrollback buffer's worth of content.

I have iTerm2 (Mac) Build 3.6.4 - this is the latest. The flicking seems to have stopped. Fingers crossed. Will report back if this continues.

A lot of people have this issue since several months now, can we at least get a statement from the claude code team ?

mine seems to happen when I instruct claud code to use parallel agents.. then the flickering really goes wild

It looks like they finally fixed the problem in version 2 0.27...

I did the update and still the same!

enableUnfocusedAcrylic doesn't work too

!clear doesn't help either

mine seems to happen when I instruct claud code to use parallel agents.. then the flickering really goes wild

No, with the version 2.0.27, parallel agents are not triggering this. I think this is fixed.

I'm pretty sure all flickering the problems I've seen before are fixed in 2.0.27. @iirekm I suggest filing a separate bug report with concrete repro steps.

2.0.28 and flickering like Christmas lights on cocaine.

• macOS Tahoe and the latest vscode intgrated terminal using zsh

2.0.28 still flickering on Win11 Windows Terminal WSL2 Ubuntu

2.0.28 still flickering on Powershell/cmd Win11 Windows Terminal
Evident when the bash output content is very large or history too long

Flickering for me too, a lot, especially when using mcp tools which provide longer outputs like gemini-mcp-tool or claude context

Please ... fix ... this ... I'm on mac, and still having this. It's soo bad to work like this!

The problem is much better since version 2.0.27 but I agree that it still occurs sometimes on version 2.0.28 onward.

I have it everytime on 2.0.29...

Any news on this issue, using CC in plan mode but the terminal starts flickering I can't no more interact with CC.

I've been having this on Mac since I've started using CC, so for months.

Seems the bug is in Ink library. I am leaving this here in case it helps to track it down:

https://github.com/vadimdemedes/ink/issues/809

I don't want to add another comment to spam people, sorry. But this and other issues make Claude Code CLI really uncomfortable to use now, even though I'm almost solely a CLI person. It's starting to make me think it's either this stupidly blazingly fast development pace and/or the Node.js ecosystem to blame. CLI interfaces ought to be satisfactory stable—otherwise, why would we not just go back to GUIs?! 🤔

On Windows and it continues to happen... I'm using Pycharm as my IDE and basically more than one line of code causes the screen to flicker faster than human comprehension... sometimes for minutes at a time. Running v2.0.31.

same problem, macos lateast
claude code in vscode and webstorm.

macOS, warp. every session has this issue, every day
especially when using subagents

Same. Usually it happens when i copy/paste logs + ultrathink.

It seems extra bad if you ran two explore or more via parallel tasks

It happens in Windows and MacOS using Windsurf IDE and native terminals. The flicker get's so bad on Mac OS, I have to use the Ctrl + O key to switch in and out or the flicker will cause Windsurf to crash.

The flicker is more a constant, highspeed, never-ending scroll. This seems to get worse the longer and larger the context lasts and grows.

Please keep this bug open and unfixed. I believe in the self-correcting force of the market.

claude --version
2.0.37 (Claude Code)

Flickering in iterm2 and inside vscode terminal (which is also iterm2)

This crashes my Cursor app multiple times a day

This make working with multiple agents really hard.

any fix for this? been having this since ages, macOS & Cursor IDE.

https://github.com/anthropics/claude-code/issues/826#issuecomment-3536628513

I fixed this by setting the terminal window where claude code is running to limited number of scrollback lines.

@bcherny @ThariqS @dhollman

FYI: I've been using electerm as my SSH client with Claude Code, and interestingly, I experience
zero screen flickering during Claude's operations - the display remains completely stable.

While other terminals (native terminal emulators, etc.) all exhibit noticeable flickering when Claude Code
is actively running, electerm handles the high-frequency output smoothly without any visual artifacts.

Electerm is Electron-based and uses xterm.js for terminal rendering. Perhaps its buffering mechanism or
rendering pipeline could provide insights for resolving this issue.

Just sharing in case it helps others experiencing this problem or helps the team investigate the root
cause.

[](https://github.com/anthropics/claude-code/issues/826#issuecomment-3536628513) I fixed this by setting the terminal window where claude code is running to limited number of scrollback lines.

Didn't help for me. Fedora, gnome-terminal

It still happens every single day!! Which is very annoying!

+1 on the flickering. It crashes the IDE every few minutes.

Breaking the tasks into smaller steps and limiting file reads are helpful. However, the flickering slows me down.

Classic. Terminal stdio overflow. If history or even larger input from MCP or even Claude comes well, is a common issue with all terminals, if not capped or running in seperate threads.

+1 in Jetbrains PHPStorm with ZSH. Stops that at times but always getting back again to it after some time:

https://github.com/user-attachments/assets/48df517e-df03-4cda-8aa7-f61ac8a71d00

Imho it looks like output from some agent that's running in the background that is shown in the main view. Also happens when typing, with each keystroke.

GUYS COULD YOU PRIORITIZE THIS ISSUE?

+1 in Jetbrains PHPStorm with ZSH. Stops that at times but always getting back again to it after some time: CleanShot.2025-11-26.at.21.12.34.mp4 Imho it looks like output from some agent that's running in the background that is shown in the main view. Also happens when typing, with each keystroke.

I think the root cause might be terminal buffer saturation, not just ANSI codes.

Why it appears only in late conversation:

• Early stage: Buffer has space → smooth output
• Late stage: Buffer fills up → system forces cleanup on every line → full screen redraws →

4,000-6,700 scroll events/sec (Issue #9935)

Quick verification:
Try increasing your terminal's scrollback buffer to 50K+ lines. If scrolling delays or stops,
confirms the hypothesis.

```bash
# tmux
tmux set-option -g history-limit 50000

# or check your terminal emulator's scrollback setting
```

Short-term fix: Increase terminal buffer (user-side workaround)

Long-term fix: Claude Code CLI should manage its own output buffer instead of relying on
terminal scrollback. When buffer approaches capacity (say 10K lines), intelligently purge
oldest content. This would eliminate the problem permanently.

Just a thought - might be worth investigating at the application level rather than chasing
ANSI/terminal driver issues.

The scrollback limit is probably not a significant factor for the occurence of this Claude Code bug for me, since I use 100k lines in terminal (Ubuntu 24.04, Gnome Terminal Version 3.52.0 for GNOME 46) and 1M lines in tmux.

Moreover, the Claude Code scrolling bug occurs, and then disappears seemingly randomly within the same Claude Code session.

Always happens to me on M4 air pycharm terminal reworked 2025.

Claude using MCP agents triggers it 100% of the time.

Always happens too, on mac terminal, vs code terminal (mac), wsl ubuntu terminal and wsl vs code terminal. Any time the historic becomes too big or using sub agents.

You can stop the flickering conversation by pressing ESC. Then run "!clear", which clears the terminal history, but keeps the context. Then just say "continue" and it's all good.

I read about this tip, it actually does not work on my side, flickering is happening anyway at some point. (And still 100% for sub agent runs whatever clearing is done).

This makes it extremely difficult to use!

I am tired of this behaviour - can you please fix this issue?

Hi i fixed it for me by changing history to a small value but that should not be the solution in general.. any advice?

Bumping this up. Just for the numbers

"me too"

yes, same thing. Claude code is a very good product but this issue is really annoying. Please try to find at least a definitive workaround if you can't fix it.

I just don't get how this is not top priority, being the highest complaint on their github!

fix it please.

fix it its annoying im paying 220 euro a month to get buggy slop

The reason its not fixed is because it is a difficult bug to fix:
https://x.com/_catwu/status/1998836023519047773?s=20

<img width="917" height="300" alt="Image" src="https://github.com/user-attachments/assets/195aec98-7332-408b-acfc-569926c300fe" />

---

Side note: This is likely an issue in the library used for the terminal UI
https://github.com/vadimdemedes/ink/issues/450#issuecomment-1836274483

The same library is used in Claude Code, Codex, Gemini CLI so I suspect they all have the same issue.

Hey so I had Claude do some digging:

If you want to see how insanely complex this is, take a look here:
https://github.com/google-gemini/gemini-cli/issues/4245

Promisingly though, recently a feature was added to Ink (as mentioned it's used for terminal UI output) to basically only render new lines (already added to gemini-cli):

<img width="711" height="498" alt="Image" src="https://github.com/user-attachments/assets/597b9ce5-3bea-4185-a680-b0ba11869c14" />

https://github.com/vadimdemedes/ink/pull/781

There is also apparently a way of writing output to a buffer and only rendering the buffer after receiving an escape sequence. It's supported by most terminals now, and this was mentioned by somebody on the Ink discussions back in May. But it seems nobody noticed. I couldn't find the sequence in the Ink code, despite his claims (in the link below) that it eliminated the flicker 🤨 🤔 :
https://github.com/vadimdemedes/ink/discussions/715#discussion-8280497

More here:
https://github.com/contour-terminal/vt-extensions/blob/master/synchronized-output.md#semantics

FYI I just ran /clear and that is not the same thing as !clear -- the second one is recommended above, the first one totally nukes your context window.

I can't believe after 6 months of dealing with this seizure-inducing issue it's still there, with the world's top AI coding company. Inexcusable.

Because of this, I want to use a different platform.

This keeps on crashing my IDE (Cursor). How is this still not fixed when the issue has been reported 6 months ago??

This issue still happening daily. RIP.

Hey so I had Claude do some digging: If you want to see how insanely complex this is, take a look here: google-gemini/gemini-cli#4245 Promisingly though, recently a feature was added to Ink (as mentioned it's used for terminal UI output) to basically only render new lines (already added to gemini-cli): <img alt="Image" width="711" height="498" src="https://private-user-images.githubusercontent.com/71481/525073843-597b9ce5-3bea-4185-a680-b0ba11869c14.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NjU5NTY5ODUsIm5iZiI6MTc2NTk1NjY4NSwicGF0aCI6Ii83MTQ4MS81MjUwNzM4NDMtNTk3YjljZTUtM2JlYS00MTg1LWE2ODAtYjBiYTExODY5YzE0LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTEyMTclMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUxMjE3VDA3MzEyNVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTg3NjNhM2JhZGU2NWYzNDFlOWYxMmRhZGQ2OTI1YzFhMGNlNWQ3OWZjNDA5MTE4YWNjMWY2NmZkMzVjZjg2OTMmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.y380nHuJGnznKJJiPjIEIiOGGR2mVY70DIYV3gv3sVo"> vadimdemedes/ink#781 There is also apparently a way of writing output to a buffer and only rendering the buffer after receiving an escape sequence. It's supported by most terminals now, and this was mentioned by somebody on the Ink discussions back in May. But it seems nobody noticed. I couldn't find the sequence in the Ink code, despite his claims (in the link below) that it eliminated the flicker 🤨 🤔 : vadimdemedes/ink#715 (comment) More here: https://github.com/contour-terminal/vt-extensions/blob/master/synchronized-output.md#semantics

How can we notify them that there is a fix? They probably have no idea.

@

Vote for Claude Console OS here. ;-)

Vote for Claude Console OS here. ;-)

I think they've messed up by sinking everything into the terminal. Could have had a far better experience with a web portal. Buttons and all sorts of things, and buffer issues would be non-existent and easy to fix. The CLI should just be the backend that spins up a local frontend webserver. You can't even click around in the terminal, it's annoying.

We should not open a discussion about it right here, but I love the terminal so much in a dynamic world. My OS is refering to get the console as Open Source (the terminal interaction at least), claude is using internally some hidden binaries hindering us of patching...

I think they've messed up by sinking everything into the terminal. Could have had a far better experience with a web portal. Buttons and all sorts of things, and buffer issues would be non-existent and easy to fix. The CLI should just be the backend that spins up a local frontend webserver. You can't even click around in the terminal, it's annoying.

My 0.02$ : I disagree. Being CLI is the best tool to work under any circumstance, from my IDE, my terminal, even on my remote machine, having multiple instances in parallel , run behind screen and all those scenarios, that would fail, if Claude CODE was just another UI appl. I wouldn't fit my needs in half my working scenarios.

Still the bug (although with me with Kitty -- Linux) rarely happens again, maybe never) I understand and it is annoying. The optimal solution, for me, would have been to open source the CLI. It's not the power of the CLI after all, it is the service that the provide what I pay for.

Anthropic talks about AI safety every day. But they can't fix a terminal bug that literally causes seizures. 💀💀💀

Maybe need some fundraising for this, any volunteers...

https://x.com/trq212/status/2001439019713073626
Thariq whom works at Anthropic on Claude code posted:

We’ve rewritten Claude Code’s terminal rendering system to reduce flickering by roughly 85%. We wanted to share more about why this was so difficult, how the fix works and how we used Claude Code to fix it 🧵

Tl;dr
Rendering in TUI is butt pain but we are getting better at it.

https://x.com/trq212/status/2001439019713073626 Thariq whom works at Anthropic on Claude code posted: > We’ve rewritten Claude Code’s terminal rendering system to reduce flickering by roughly 85%. > We wanted to share more about why this was so difficult, how the fix works and how we used Claude Code to fix it 🧵 Tl;dr Rendering in TUI is butt pain but we are getting better at it.

Weird, I haven't noticed any improvement at all. 85% huh?

The optimal solution, for me, would have been to open source the CLI

Open source is not a silver bullet, and does not automagically heal any problem.
You can always build your own CLI tool, and release it under a permissive license, which does not require a million GPUs.

Hey so I had Claude do some digging: If you want to see how insanely complex this is, take a look here: https://github.com/google-gemini/gemini-cli/issues/4245

That's whaw I though also, even got Claude to patch itself to use incremental option, but the flickering was still there. Ended up ~~writing~~ vibe coding an agent multiplexer with agents in panes like tmux and inter-agent communication messaging system.

A months-long critical bug - great built-in advertising for vibe coding

@vmitro thanks! been using https://github.com/vmitro/bukowski for almost a week, it's great! The only thing that worked for me.

@isarandi You're welcome! After the latest fix by Anthropic you may encounter some slowdowns when using the latest bukowski version with more than one Claude Code pane.

The newest version spawns terminals with 24 rows instead of hardcoded 500 ones, which eliminates the need to scroll all the way up when starting new sessions, plus it's got some vim motions and a chat MCP server for inter-agent communication. When installed, each of the three supported agents (Claude, Codex, Gemini) get a globally available FIPA ACL MCP tool and a system prompt reminder that they can use it. You can e.g. tell Codex to examine the implementation Claude just did and offer feedback to Claude, than you can tell Claude to check its inbox. Works surprisingly well.

The most frustrating part is that we have no feedback at all from Anthropic regarding the progress on this bug, which in my opinion is the most impactful one in terms of usability. There is no point in releasing highly performant models that could take us to Mars if we can’t even use them properly due to a bug in a simple terminal.

Anthropic posted in https://github.com/anthropics/claude-code/issues/769#issuecomment-3667315590 the summary of the 2.0.72 release changes, which reduce flickering for some terminal types.

@chrislloyd - do you think this issue should be closed as well, and users encourage to submit separate bug reports, stating the details like operating system, claude code version, and terminal type and version?

@nullbio Have you tried skills? I have, and I ended up with an Out of Memory Error, so I ended up goimg back to agents. I have a fairly large codebase comprising a framework for distributed data orchestration for machine learning via ZeroMQ and utilizing its modified and extended Majordomo protocol. The enduser should be able to define their pipelines as series of steps in a YAML file, where each step has a message type that it "consumes", e.g. a string, or a file, or a list of ints/floats, or a good ole JSON; the messages get serialized into ZMQ Dealer/Router frames and sent via wire back and forth. For each pipeline, the broker maintains an ephemereal state machine, which can either process the steps in a continous mode, or in a sort of like debugger mode, where the pipeline pauses after each step and the client that started it can either accept, reject or correct the worker's, well, work. A sort of Human-in-the-Loop as primitive. The pipelines also have streams as primitives, which map loosely on Lucid (the dataflow language's) notion of streams as "value in the dimension of time", and those pipelines can get started automatically when e.g. a file in the virtual file system has been changed, or a directory gets filled with N of fresh files, or (planned) a raised event which can also carry some mutable value...

Anyway, this is getting rather complex (as you can read) and what I've settled on is - I asked Claude to design an agent called style guide. The agent maintains its local knowledge base as a collection of themed .md files with a main .md file acting as a sort of index; I don't auto accept changes most of the time, if I notice that Claude utilized a pattern that is not the "framework way" of doing things, I just reply that he should check with @agent-style-guide if this pattern is acceptable, if not, he should change it, if the agent thinks a new pattern could be derived for the specific case, but in the spirit of the "framework way", it should update the knowledge base.

When starting a new session, this is paramount, and I rely most often on auto compaction in order not to lose the valuable context information, but it gets lost from time to time anyway, and I usually askt Claude to consult the style guide agent every 3rd or 4th implementation.

Anthropic posted in #769 (comment) the summary of the 2.0.72 release changes, which reduce flickering for some terminal types. @chrislloyd - do you think this issue should be closed as well, and users encourage to submit separate bug reports, stating the details like operating system, claude code version, and terminal type and version?

Why should it be closed? It hasn't been solved. As for the "reduced flickering" - I haven't noticed any reduction at all.

Why should it be closed? It hasn't been solved. As for the "reduced flickering" - I haven't noticed any reduction at all.

It is due to the "zero open issues policy" ...

https://github.com/anthropics/claude-code/issues/769#issuecomment-3667315590 explains at the bottom

... feel free to open new issues for specific bugs you encounter.

This means that if anyone experiences flickering still, they can open an issue with details of their system, including the terminal type and version, and Anthropic will provide help, as they did in https://github.com/anthropics/claude-code/issues/14393.

I've been away from CC for a few days and was encouraged by the note about "reducing flicker by 85%" by @ThariqS

All of this talk about closing this issue was also encouraging.

Sadly, I will clarify, flicker is not dead:
https://github.com/user-attachments/assets/957a7675-e705-4dcf-9a68-8b8fa5779639

Above a screen capture from the latest Claude Code v2.0.75 on Ubuntu. Perhaps the fixes are not yet pushed to main?

_"The reports of my death are greatly exaggerated."_ -Claude Code Flicker

After endless crashing sessions and almost giving it up on Claude Code the solution came from Gemini which made my day. Putting it as it is:

1. Disable GPU Acceleration in VS Code

The infinite redraw loop is often triggered by VS Code's attempt to hardware-accelerate the terminal display. Turning this off forces a more stable software rendering mode.
Open Settings (Ctrl + , or Cmd + ,).
Search for Terminal Integrated Gpu Acceleration.
Set it to off.
Restart VS Code completely.

Now it is even adaptive to resizing terminal :)

Note after several days: I was too early to celebrate, it is still flickering with long running sessions

After endless crashing sessions and almost giving it up on Claude Code the solution came from Gemini which made my day. Putting it as it is: 1. Disable GPU Acceleration in VS Code The infinite redraw loop is often triggered by VS Code's attempt to hardware-accelerate the terminal display. Turning this off forces a more stable software rendering mode. Open Settings (Ctrl + , or Cmd + ,). Search for Terminal Integrated Gpu Acceleration. Set it to off. Restart VS Code completely. Now it is even adaptive to resizing terminal :)

I'm just using a regular terminal over here.

The remaining flickering in long sessions appears to be a concurrent rendering issue.

Suggest implementing event sequencing at the render handler level:

• Unified render event (single entry point for all terminal writes)
• Sequential processing with state tracking (prevent re-entrant writes)
• Time-window batching (~16ms) + backpressure control

This should resolve the race conditions causing both flickering and navigation issues.

So I can see this is really getting to some people.
So I follow most of the devs on X and the story from what I've seen is...

2.0.72 - was released with a complete rendering rewrite and according to many it improved the situation a lot. For others it didn't help
https://github.com/anthropics/claude-code/issues/769#issuecomment-3667315590

Unfortunately the fix also lead to significant performance degradation for many users on longer conversations. They made the decision to roll back the fixes in one of the later releases (not sure which). This is why most people here have not seen the improvement.

I would suggest people try

claude install 2.0.72

however I'm personally running into errors with that command

However, if it is really unbearable, perhaps the npm version will work for people while you wait for the full fix release

npm install -g @anthropic-ai/claude-code@2.0.72

Reading between the lines, I suspect they need more time for the proper flicker bug release (especially given its Christmas and they likely want to spend it with family).

Dear Claude Code Anti-Flicker Community,

Thanks to @chrislloyd and @marcindulak for recommending here a CLI solution to eliminating flicker: _Ghostty_.

I can confirm the solution works on both Ubuntu and Mac. It is a modern and elegant terminal UI.

Here is a screenshot of the Claude Code CLI on MacOS with background-opacity = 0.8:
<img width="1241" height="970" alt="Image" src="https://github.com/user-attachments/assets/782286f1-2912-436c-93cb-f0a853f844cb" />

Merry Christmas! 🎄

Also, for windows user, Windows Terminal Canary also supports synchronized update control sequences, unfortunately not for stable yet.

I have flickering in Ghostty, running zsh in tmux, it's the only agent cli that does flicker btw, not sure if that matters for comparative analysis

Validated Fix for Terminal Flickering

I've developed and validated a fix for this issue in a separate project (RemoTerm). Here's the root cause analysis and solution.

Root Cause

The v2.0.72 fix was rolled back because it introduced typing latency. The problem: render operations blocked input handling because both used the same event loop priority.

BEFORE (flickering): direct writes cause tearing
AFTER v2.0.72 (latency): keypress → render() → echo appears (blocked)

Solution: Three-Layer Architecture

The fix decouples input from rendering using Node.js event loop priorities:

| Layer | Problem Solved | Mechanism |
|-------|----------------|-----------|
| Priority Scheduling | Typing latency | process.nextTick (input) vs setImmediate (render) |
| Synchronized Output | Visual tearing | DEC 2026 escape sequences |
| Pre-resize Flush | Small terminal flicker | flushSync() before dimension change |

Key Code Pattern

class TerminalRenderer {
  private pending: string[] = [];
  private scheduled = false;

  // HIGH priority: input echo (never blocked by render)
  echoInput(char: string): void {
    process.nextTick(() => process.stdout.write(char));
  }

  // LOW priority: batched output with sync wrapping
  write(data: string): void {
    this.pending.push(data);
    if (!this.scheduled) {
      this.scheduled = true;
      setImmediate(() => this.flush());
    }
  }

  private flush(): void {
    // DEC 2026 synchronized output for atomic visual update
    const output = '\x1b[?2026h' + this.pending.join('') + '\x1b[?2026l';
    process.stdout.write(output);
    this.pending = [];
    this.scheduled = false;
  }

  // CRITICAL: Call before any resize operation
  flushSync(): void {
    if (this.pending.length > 0) this.flush();
  }
}

Why This Works

1. Input never blocked: process.nextTick runs before setImmediate in Node.js event loop
2. Atomic updates: DEC 2026 tells terminal to buffer until complete
3. Resize safety: Flushing before resize prevents stale content display

Validation Results

Tested in RemoTerm (xterm.js-based terminal):

• ✅ No flicker at 1841+ lines of output
• ✅ No typing latency regression
• ✅ tmux 3.2+ passthrough working (DEC 2026 forwarded)
• ✅ Resize to small terminals (~100 cols) works without flicker

Integration with Claude Code

Claude Code already uses 2000-char batched writes. Integration points:

1. Route short data (1-4 chars) through process.nextTick as input echo
2. Wrap batch output in \x1b[?2026h...\x1b[?2026l
3. Add flushSync() call before any terminal resize

Reference Implementation

Full working implementation available at:

• renderScheduler.ts - Priority-based batching (274 lines)
• inputPriorityRouter.ts - Input echo detection (197 lines)
• terminalCapabilities.ts - DEC 2026 detection (203 lines)
• syncOutput.ts - ANSI constants (146 lines)

Happy to provide the full source if helpful for the fix.

🤖 Generated with Claude Code

https://github.com/user-attachments/assets/25d48dbd-3d02-41be-b1ea-45e210564779

Reference Implementation Available

The full working implementation is available in the RemoTerm project:

Repository: https://github.com/SvetimFM/multipass-terminal

Key files for Claude Code adaptation (Node.js only - ignore xterm.js parts):

| File | Purpose | Applicable to CC? |
|------|---------|-------------------|
| src/services/renderScheduler.ts | Priority scheduling with process.nextTick vs setImmediate | ✅ YES |
| src/services/inputPriorityRouter.ts | Input echo detection (1-4 char heuristic) | ✅ YES |
| src/utils/syncOutput.ts | DEC 2026 ANSI constants | ✅ YES |
| src/services/terminalCapabilities.ts | tmux 3.2+ detection | ✅ YES |
| src/public/js/modules/* | xterm.js client-side buffering | ❌ Not applicable |

Demo video showing no flicker at rapid output is attached to this issue.

The core fix for any Node.js CLI is just ~50 lines:

class TerminalRenderer {
  private pending: string[] = [];
  private scheduled = false;

  echoInput(char: string): void {
    process.nextTick(() => process.stdout.write(char));
  }

  write(data: string): void {
    this.pending.push(data);
    if (!this.scheduled) {
      this.scheduled = true;
      setImmediate(() => this.flush());
    }
  }

  private flush(): void {
    const output = '\x1b[?2026h' + this.pending.join('') + '\x1b[?2026l';
    process.stdout.write(output);
    this.pending = [];
    this.scheduled = false;
  }
}

Happy to help with any questions on adapting this to Claude Code's architecture!

## Additional Root Cause: Line Count Calculation Error

Besides the rendering priority issue, I found another flicker source:

Problem: When tools/MCP return results, the line count calculation causes a 1-line shift because the renderer recalculates the entire output from scratch each time.

Suggestion: Implement a state manager to track output segments incrementally:

• Record each segment's line range (tool_use, tool_result, messages)
• Update only affected segments when new content arrives
• Adjust subsequent line offsets without full recalculation

This should eliminate cumulative line count errors. The team can trace through the rendering pipeline
to see where the recalculation happens.

Especially problematic with streaming tool messages where incremental updates compound the calculation error.

Before optimizing with Rust, please fix the basic string handling that worked in 2.0.67」

Dear Claude Code Anti-Flicker Community, Thanks to @chrislloyd and @marcindulak for recommending here a CLI solution to eliminating flicker: _Ghostty_. I can confirm the solution works on both Ubuntu and Mac. It is a modern and elegant terminal UI. Here is a screenshot of the Claude Code CLI on MacOS with background-opacity = 0.8: <image> Merry Christmas! 🎄

Unfortunately, this is not true at all. I still experience the flickering ~7/10 times with the Claude Code CLI in Ghostty. There's a great chance it's because I use tmux, but even more custom rendering cli tools such as opencode and amp — where you have rich and advanced scrolling, navigation and focusing —, using tmux is a non-issue.

I'm on macOS 15.7.1.

Guys, you're not adding any value with all these comments. Anthropic is already aware of this issue and is working on it as one of their highest-priority tasks. It's a work in progress. It'll take a while: https://x.com/trq212/status/2001439019713073626

Please stop spamming everyone who is subscribed.

Yeah, I was seeing it again in bukowski after the newest update. The one that was fixed and then rolled back used to work, although the fix caused major slowdowns, especially when dealing with "tell Claude what do do instead" and typing.

The Anthropic team insist on letting our terminals handle the scrollback but also on using reactive rendering as if terminal was a web app... IMHO, there are two approaches at this, A) ditch ink.js and rewrite the rendering engine from ground up, or B) patch the ink.js upstream for the benefit of all (if not already patched -- I know they bundle a vendored ink.js so any changes on the official release wouldn't reflect in CC). Or - C) write a heuristicsoft terminal emulator wrapper around a headless xterm.js to circumvent all of CC's rendering bugs (what I do with bukowski).

still happening in v2.1.1 in WSL

I have a similar problem on mac.

https://github.com/user-attachments/assets/8864aa1a-f36e-4cd7-b2e2-dcb7249edcf2

npx --yes envinfo --system --binaries --managers

  System:
    OS: macOS 26.1
    CPU: (8) arm64 Apple M3
    Memory: 84.02 MB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 22.19.0 - ~/.nvm/versions/node/v22.19.0/bin/node
    Yarn: 1.22.22 - ~/.nvm/versions/node/v22.19.0/bin/yarn
    npm: 10.9.3 - ~/.nvm/versions/node/v22.19.0/bin/npm
    pnpm: 9.15.9 - ~/.nvm/versions/node/v22.19.0/bin/pnpm
    bun: 1.2.19 - ~/.bun/bin/bun
  Managers:
    Homebrew: 5.0.8 - /opt/homebrew/bin/brew
    pip2: 19.2.3 - ~/.pyenv/shims/pip2
    pip3: 23.0.1 - ~/.pyenv/shims/pip3
    RubyGems: 3.0.3.1 - /usr/bin/gem

Drop this in your .zshrc or .bashrc or whatever else you have for your shell: export ENABLE_INCREMENTAL_TUI=true

ENABLE_INCREMENTAL_TUI=true

@xHeaven do you have a doc about this env variable? Couldn't find any info about it

> ENABLE_INCREMENTAL_TUI=true @xHeaven do you have a doc about this env variable? Couldn't find any info about it

It's completely undocumented officially (or by any source at all).

Basically, if you don't provide this environment variable, your TUI will render with the v1 engine (render_v1), if you provide it, it'll render with the v2 engine (render_v2). There's also an internal feature flag called tengu_sumi that enables v2, so Anthropic is probably A/B testing this.

The v1 engine is (obviously) older and buggier. It does string based comparison, so when content changes in your TUI, it counts the lines of previous output, clears them, and redraws everything. Also, the v1 engine literally has a function in its render path called getRenderOpsForAllOutput_CAUSES_FLICKER. Oh well.

The v2 engine is much more sophisticated. It maintains a cell based screen buffer where each cell tracks its character, style, width, etc. It uses dirty flags on nodes and damage region tracking to know exactly what changed. When rendering, it diffs the old and new screen cell by cell and only emits updates for cells that actually differ. Unchanged regions get copied from the previous frame. It also does proper grapheme segmentation for unicode/emoji via Intl.Segmenter, and pools/interns text styles for efficient comparison.

It's essentially a virtual DOM diffing approach applied to terminal rendering. In my tests, it used a bit more memory (those cell buffers add up) but less CPU on typical updates since it's not redrawing the world every frame.

In the end, though, both engines still fall back to full redraws on resize or when content scrolls offscreen, so it's not perfect, but v2 is noticeably smoother.

@xHeaven thank you! Sounds exciting and just enabled it. Let me see if it improves at all

It's one of worst experience I've had in my life. I don't want Claude Code on Desktop, I'm not even asking for being able to use it on other tui/cli. I just wanted it to work, to render properly.

It should at the very least be able to do a very basic thing: render text on the terminal.

Go back to the zero, I don't care anymore, make it a plain ol' cli UX, but at the very minimum it should work and render properly.

It's unbelievable this is a discussion. I don't care how sophisticated rendering on the terminal has gotten, I really don't. I've never experience such infuriating experience in my life like this one.

Claude Code 2.1.3 fixes flickering for me, it is now awesome!

Claude Code 2.1.3 fixes flickering for me, it is now awesome!

With ENABLE_INCREMENTAL_TUI=true, or without?

With ENABLE_INCREMENTAL_TUI=true, or without?

Yes I also do have it

1. Please return to terminal fundamentals. If you're building a CLI terminal, build it the terminal way.

1. Terminal is one of the oldest and most mature technologies in computing. Seven months to solve what

was already solved decades ago.

1. Is this a technical problem, or an architectural problem? I believe Claude—your own AI—can answer that for you.

1. I'm losing patience.

> With ENABLE_INCREMENTAL_TUI=true, or without? Yes I also do have it

Still flickering for me, nothing changed.

ENABLE_INCREMENTAL_TUI=true

Unfortunately this completely breaks tmux scrollback buffer (wezterm/macos).

If we could just get a basic TUI mode with none of the fancy stuff (I dont need keyboard combinations in a TUI, just let my press (Y)es (A)lways (N)o, ) that would be quite enough. Clearly vibecoding can not get claude code into a working TUI state

It really does feel like Anthropic just can't keep up. Now they're enforcing a ban on using third party cli's like Open Code when they perform better than Claude Code does, yet they don't fix these fundamental severe issues. Like, maybe the lesson isn't: "Hey, this open-source alternative has grown to 1m active monthly users, we should stop people from using their sub on other clients", maybe the lesson should be: "If we open source our own client, we can make Claude Code the best on the market and keep people in the Anthropic ecosystem, while also leaving a good impression."

I'm inclined to say yes to every plan claude give me because if I say no with comments, I'll have a crazy headache 😂

This flicker is gonna cause me a seizure someday.

Everyday I come to this thread, hoping Anthropic will finally do something... please fix it or open-source CC so we can fix it for you.

Everyday I come to this thread, hoping Anthropic will finally do something... please fix it or open-source CC so we can fix it for you.

Every. Single. Day.

oof this issue is very glaring on windows terminal using wsl1 with ubuntu. Looks really janky

yeah i check this everyday, sad to see still no fix. I use Alacritty on MacOS, but also have this happen in Kitty and ITerm2, and in Cursors terminal pane. Really sad because Claude Code is super powerful, and i like the experience a lot more thanks to it being a TUI, i am always in a tmux session. Never seen such a large project struggle with TUI rendering, maybe look at how htop or Bottom handle it. They both render live data to a TUI with no flickering issues during renders, with infinitely long process lists.

This has been driving me crazy so I recorded a session and looked at what CC is actually sending.

CC uses synchronized output (\x1b[?2026h...\x1b[?2026l) in chunks for its entire output. Except for the first chunk, the rest of the chunks fill the following two patterns:

(Size from a 120K session recording (3.5GB of terminal data recorded))

| Pattern | Frequency | Avg Size |
|---------|-----------|----------|
| Line clearing (\x1b[2K + \x1b[1A repeated) | 55% | 2.7 KB |
| Full screen clear (\x1b[2J + \x1b[3J + \x1b[H) | 45% | 94.5 KB |

The full screen clears being spammed are what causes the issue.

Hopefully CC can get this fixed properly. In the meantime I wrote a workaround that intercepts sync blocks, detects full screen clears, and truncates to last 100 lines. I've used it without major issues on tmux/debian if it helps anyone: https://github.com/davidbeesley/claude-chill I don't think it would be a lot of work to get it working on macos as well, it's not a big codebase.

EDIT: Added support for macos

Sign my petition please guys: #18451 - Maybe if we get enough momentum, we can fix Claude Code's name.

I've been here before. I am able to have it working on Windows 11 with Git Bash without the flickering. I had to uninstall Claude AND GitBash and then re-install Claude THEN GitBash. Order of installation here was important for some reason. Hope this helps

I was having this issue in MobaXterm terminal on Windows 11. Today installed WezTerm and still have the same.

Having massive issues with ITerm2 for the last few days or weeks. It's _REALLY_ annoying to the point that I am considering abandoning Claude Code, even tho I fucking love it. It's just unbearable.

This has been driving me crazy so I recorded a session and looked at what CC is actually sending. CC uses synchronized output (\x1b[?2026h...\x1b[?2026l) in chunks for its entire output. Except for the first chunk, the rest of the chunks fill the following two patterns: (Size from a 120K session recording (3.5GB of terminal data recorded)) Pattern Frequency Avg Size Line clearing (\x1b[2K + \x1b[1A repeated) 55% 2.7 KB Full screen clear (\x1b[2J + \x1b[3J + \x1b[H) 45% 94.5 KB The full screen clears being spammed are what causes the issue. Hopefully CC can get this fixed properly. In the meantime I wrote a workaround that intercepts sync blocks, detects full screen clears, and truncates to last 100 lines. I've used it without major issues on tmux/debian if it helps anyone: https://github.com/davidbeesley/claude-chill I don't think it would be a lot of work to get it working on macos as well, it's not a big codebase. EDIT: Added support for macos

Just want to say this seems to be working extremely well so far, thanks for adding the MacOS support. Immediately went from a flickering mess to nice and quiet TUI tool.

Why is this issue still not fixed? With all the billions at your disposal you cannot address this super annoying bug that makes your best piece of software unusable?

> > ENABLE_INCREMENTAL_TUI=true

So far, this seems to have improved the problem significantly. It's not perfect, but it's much better. Thanks!

This has been driving me crazy so I recorded a session and looked at what CC is actually sending. CC uses synchronized output (\x1b[?2026h...\x1b[?2026l) in chunks for its entire output. Except for the first chunk, the rest of the chunks fill the following two patterns: (Size from a 120K session recording (3.5GB of terminal data recorded)) Pattern Frequency Avg Size Line clearing (\x1b[2K + \x1b[1A repeated) 55% 2.7 KB Full screen clear (\x1b[2J + \x1b[3J + \x1b[H) 45% 94.5 KB The full screen clears being spammed are what causes the issue. Hopefully CC can get this fixed properly. In the meantime I wrote a workaround that intercepts sync blocks, detects full screen clears, and truncates to last 100 lines. I've used it without major issues on tmux/debian if it helps anyone: https://github.com/davidbeesley/claude-chill I don't think it would be a lot of work to get it working on macos as well, it's not a big codebase. EDIT: Added support for macos

Hey! I saw your workaround and decided to take a stab at fixing the root cause.

I've submitted PR #19 that replaces the auto-lookback (which was causing those full
screen clears every 5s) with an incremental scrollback sync mechanism:

What changed:

• Disabled the timer-based auto-lookback that was spamming [2J[H
• Added sync_scrollback_incremental() that does pure bytes-level diff
• Only sends new content since last render (no repeated output)
• Only activates when screen ≥ 23 lines

Result:

• ✅ No more screen flickering
• ✅ Smooth scrollback with mouse wheel
• ✅ Minimal code changes (+42 net lines)

Testing:
I've done initial testing with various output sizes (20/30/100 lines) and real usage.
Everything seems to work, but there might be bugs since this is just preliminary testing 😅

The approach is basically:
``rust
// Every render (when needed):
current_dump = history.dump()
new_content = current_dump[buffer.len()..] // bytes diff
send(new_content) // incremental only
buffer = current_dump
``

Would love your feedback on the approach! The PR has full details:
https://github.com/davidbeesley/claude-chill/pull/19

Release notes from Jetbrains mentions that this issue is fixed with their IDEs 👀

!Screenshot_20260123_041225_Chrome.jpg

Release notes from Jetbrains mentions that this issue is fixed with their IDEs 👀 !Screenshot_20260123_041225_Chrome.jpg

It's a sad day when software providers have to work around this because Anthropic is taking so long...

It's a sad day when software providers have to work around this because Anthropic is taking so long...

I think you misunderstood @nullbio . It seems like Jetbrains just added a feature that existed in many other terminals for a long time, which CC already supported. They fixed their own terminal by adding output synchronization support. So you are blaming the wrong side for that delay.

I'm on Claude Code 2.1.19, tmux, Ghostty and macOS Sequoia. And it's still very much happening. I can't believe it.

I give up on this, I'll give @davidbeesley solution a try, but all I wanted was to just uninstall this cli.

Discovery: Build Your Own TUI for Claude Code (Bypass the Flickering)

Problem: Built-in TUI has severe flickering issues (#1913), and you can't customize it.

Solution: claude -p --input-format stream-json --output-format stream-json

Key insight: Keep stdin open = persistent process. As long as you don't close the stdin pipe, CLI stays alive for multi-turn conversations!

Message format: {"type":"user","message":{"role":"user","content":"your message"}}

I built a 250-line Rust terminal wrapper: stdin pipe stays open → process never exits → full control over rendering → zero flickering.

Suggestion to Anthropic: Please document this headless mode officially, so developers can build their own TUI/GUI/Web interfaces.

Freedom: Any language, any UI framework, any platform. You own the pixels. 🚀

Discovery: Build Your Own TUI for Claude Code (Bypass the Flickering)

............

Freedom: Any language, any UI framework, any platform. You own the pixels. 🚀

"Made a fun retro TUI demo for Claude CLI - just basic chat with a zen meditation loading animation. Nothing fancy, but take a look if you're curious: https://github.com/woolkingx/claude-tui-rs"

For Windows Terminal Canary 1.25.10231.0, at least, it should go under the profiles node, not the defaults node (because it's global)

I put it here in the bottom

    },
    "schemes": [],
    "tabWidthMode": "titleLength",
    "themes": [],
    "useAcrylicInTabRow": true,
    "compatibility.enableUnfocusedAcrylic": false,
    "windowingBehavior": "useAnyExisting"
}

Not a Claude Code user, but people keep mentioning this problem so I had a look and I think it's really trivial to fix.

The problem is in the open source "Ink" library that Claude Code uses. It writes ansiEscapes.clearTerminal here to clear the terminal before writing the updated lines.

If you want a TUI page update to not flicker, you don't clear lines like that. Instead you just write the updated lines and include a clear to end-of-line (ansiEscapes.eraseEndLine) at the end of each one, as described in this SO answer.

This should be a single-digit line patch to Ink to fix if someone's in the mood (not me as I don't use it).

Edit: Actually, that clearTerminal call is in this if statement, so it looks like it's intended for when the terminal changes size (though I'm struggling to see how that comparison is correct).

The actual writing to stdout goes through a log class from this file. There are two variants of that, one that uses eraseLines and will flicker, and an "incremental" variant that is enabled via an option. The incremental variant does the right thing by adding eraseEndLine instead of using eraseLines. It also avoids writing lines at all when they are unchanged.

So my guess is either the incremental rendering isn't enabled or there's something wrong with that comparison to detect terminal resizes, and it's causing the clearTerminal to always happen. (Should be able to check which by capturing stdout and seeing what escape codes were written.)

Ah, that's a shame. I npm installed it and had a look at the code, and while it does have something that looks like Ink in it, with some strings including the ink url and some recognisable code (and that project lists Claude Code as a user), the rendering code looks very different and there's no sign of the incremental rendering feature of Ink.

It seems solved in WSL2
Version: 2.1.39
brew installation

Version 2.1.76 has brought back that flickering issue. I hadn't noticed it for a long time, but now it seems to have returned. It's really inconvenient to watch what's happening during the process because when you scroll up in the terminal, for example, in Linux Mint xterm, the flickering constantly jumps you back to the top of the chat window. This makes it impossible to track the progress of the work.

Confirming it has come back, you can't track anything and that raises health concerns, because it's basically like looking at a strobe light right now.

This has come back, I am still facing this issue, version 2.1.76

Also dealing with this issue again on 2.1.77

I posted about the auto-scrolling issue here:
https://x.com/Gerry/status/2035434987072200824

Otherwise I doubt this regression will be noticed.

Still seems to be an issue with latest versions:

Environment:

• Windows 11 Pro (10.0.26200)
• PhpStorm latest EAP (2026.1 RC)
• Claude Code 2.1.84 (via PhpStorm plugin)
• Terminal shell: PowerShell 7 (C:\Program Files\PowerShell\7\pwsh.exe, latest version)
• Claude Code model: Opus 4.6

This is likely the same root cause as #769 — Ink (Claude Code's TUI framework) redraws the full viewport on updates.
See my workarounds in #769: https://github.com/anthropics/claude-code/issues/769#issuecomment-4159597854
TL;DR:

1. tmux — adds a buffer layer that reduces visible flickering
2. Lower terminal refresh rate — iTerm2, Kitty settings
3. Switch terminals — Ghostty/Kitty tend to flicker less
4. Headless mode (claude -p) for long tasks — no TUI, no flicker

export CLAUDE_CODE_NO_FLICKER=1 might be worth a shot

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