Hi! I work on TUI rendering for Claude Code. I know this has been a long-standing frustration — it's taken longer than any of us wanted.
The good news: we shipped our differential renderer to everyone today. We rewrote our rendering system from scratch[1] and only ~1/3 of sessions see at least a flicker. Very, very few sessions see flickers in rapid succession which was so annoying before. Those numbers will keep dropping as people update.
We've also been working upstream to add synchronized output / DEC mode 2026 support to environments where CC runs and have had patches accepted to VSCode's terminal[2] and tmux[3]. Synchronized output totally eliminates flickering. As always, I recommend using Ghostty which has 2026 support and zero flicker.
Why has public comms been so poor on this issue? There's been lots of Github issues posted in the Claude Code repo with lots of new comments each day screaming into the void, but radio silence from Anthropic since the revert in December. It's clearly causing a lot of frustration for users leading to clever workarounds like this.
It was obviously a complex issue (I appreciate that and your work!). But I think there's a lot to be improved on with communication. This issue in particular seems like it has lost a lot of user trust - not because it was hard to solve and took awhile - but because the comms and progress around it was so limited.
The communication is definitely on me! There honestly wasn't much new to say -I've been slowly ramping since early Jan just to be extra sure there's no regressions. The main two perf. issues were:
1. Since we no longer have <Static> components the app re-renders much more frequently with larger component trees. We were seeing unusual GC pauses because of having too much JSX... Better memoization has largely solved that.
2. The new renderer double buffers and blits similar cells between the front and back buffer to reduce memory pressure. However, we were still seeing large GC pauses from that so I ended up converting the screen buffer to packed TypedArrays.
I’m really surprised that GC is an issue at the bits/sec throughput a TUI would be pushing. At the risk of making an obvious observation: your render loop is doing way too much work for what it is producing.
I think this is the main issue. When I would get into flickering mode, it appeared that the entire TUI was re-rendering on every key press. I don’t know if it’s maybe just the limitation of Ink or even terminals.
Well vim doesn’t flicker so it’s definitely not a limitation of terminals, but you’re probably right about the Ink/React stack.
Have you guys seriously considered decoupling the TUI / UI so anyone can write their own on top of Claude Code proper? I love how Zed did it, but its not always the most stable experience, but it is definitely better than staring at a TUI.
Thanks for the update!
I believe the CC editor extensions and Zed's ACP both use the Claude Agent SDK.
Interesting, I'm only an end-user so I don't know too much about it, but the reason I ask is because of "OpenCode" or whatever it was called, that people were using instead of Claude Code itself, I figured if there was a way to make your own UI on top of Claude Code, surely OpenCode would have used it? Not sure whatever came of that whole fiasco. I never used OpenCode, but I like having the option to swap UIs as needed.
I wonder how much of Claude Code is developed using Claude?
A lot of it, and their Claude Cowork is all claude's work (according to claude code's creator).
> only ~1/3 of sessions see at least a flicker.
...after many months, for such a visible bug, is such a crazy thing to say.
In case the above comes across as too hostile, to balance this, I would say thank you to the claude code team for such an amazing product!
> The good news: we shipped our differential renderer to everyone today. We rewrote our rendering system from scratch[1] and only ~1/3 of sessions see at least a flicker. Very, very few sessions see flickers in rapid succession which was so annoying before. Those numbers will keep dropping as people update.
I'm using the latest version and see terrible flicker in tmux still. You guys should be ashamed tbh.
How tall is your tmux pane? If it's very small it might still flicker as CC tries to redraw scrollback. I've noticed several tmux users have layouts where they stack several panes on top of each other making each one quite short.
Another option is to rebuild tmux from latest source so it buffers synchronized output, which should prevent the flicker entirely.
If you're still seeing a terrible flicker please file a `/bug`!
Thanks for your response.
> How tall is your tmux pane? If it's very small it might still flicker as CC tries to redraw scrollback. I've noticed several tmux users have layouts where they stack several panes on top of each other making each one quite short.
It's full screen ("maximized" as tmux calls it).
> Another option is to rebuild tmux from latest source so it buffers synchronized output, which should prevent the flicker entirely.
I'll give it a shot.
I'm sorry for the low quality comment, but man, get some perspective.
> low quality comment
What else do you want me to say? It's ironic that one has to jump through hoops (like this post) to get basic functionality right in a tool that claims it'll replace software engineers.
Perspective is: how hard can it possibly be? It’s a TUI. This should be able to run on a calculator.
Am I missing some complexity here?
I have not used Claude Code in a couple months. THEY HAVEN’T FIXED THIS YET?
I’m starting to think that the reason why anthropic doesn’t open source Claude code isn’t due to competitive reasons, it’s because they don’t want people to see what a mess their code base is.
Maybe they bought Bun to increase the rate of flickering so that the text looks solid again
The problem is they are using the Ink library which clears and redraws for each update.
I locally patched the closed-source CLI npm package but it's not perfect. They would have to switch how their TUI is rendered on their side.
Apparently OpenAI Codex is rust+ratatui which does not have this issue.
I'm always surprised that Python doesn't have as good TUI libraries as Javascript or Rust. With the amount of CLI tooling written in Python, you'd think it had better libraries than any other language.
One reason for the lack of python might be the timing of the TUI renaissance, which I think happened (is happening?) alongside the rise of languages like Go and Rust.
it has, but python being single threaded (until recently) didn't make it an attractive choice for CLI tools.
example: `ranger` is written in python and it's freaking slow. in comparison, `yazi` (Rust) has been a breeze.
Edit: Sorry, I meant GIL, not single thread.
> it has, but python being single threaded (until recently) didn't make it an attractive choice for CLI tools.
You probably mean GIL, as python has supported multi threading for like 20 years.
Idk if ranger is slow because it is written in python. Probably it is the specific implementation.
Even my CC status line script enjoyed a 20x speed improvement when I rewrote it from python to rust.
It’s surprising how quickly the bottleneck starts to become python itself in any nontrivial application, unless you’re very careful to write a thin layer that mostly shells out to C modules.
Textual looks really nice, but I usually make web apps so I haven’t tried it for anything serious:
Textual is A++. Feels a bit less snappy than Ink, but it makes up in all things with its immense feature-set. Seriously fun building apps of all kinds with this lib.
They started with Ink but have since switched to their own renderer:
> We originally built Claude Code on Ink, a React renderer for the terminal. [...] Over the past few months, we've rewritten our rendering system from scratch (while still using React).
Thanks for sharing. Very … interesting. Just trying to understand why the heck would React be the best tool here?
React is just an abstraction of a State -> View function.
While not universally applicable, it's very convenient during development to focus on State without thinking about View, or focus on View without thinking about State.
The concept itself has nothing to do with the actual renderer: HTML, TUI, or whatever. You can render your state to a text file if you want to.
So the flickering is caused either by a faulty renderer, or by using a render target (terminal) that is incompatible with the UI behavior (frequent partial re-renders, outputting a lot of text etc.)
I genuinely thought this was satire until I looked it up. I guess it's just to make us webdevs feel at home in the Terminal (ooh, spooky!)
React separates into layers.
Any web react project out there will install react AND react-dom, which is the son implementation of react.
It’s how react translates into mobile, web, etc so well.
It defines contracts and packages like react-dom handle th specific implementation.
Building a react renderer has long been on my wish list of weekend (>1 weekend most likely) projects.
Thats the problem. Some developers want to avoid learning another programming language and use one for everything (including their technologies.)
Using TS, React here doesn’t make sense for stability in the long term. As you can see, even when they replaced Ink and built their own, the problem still exists.
There are other alternatives that are better than whatever Anthropic did such as Bubbletea (Go) or Ratatui (Rust) which both are better suited for this.
Maybe they were thinking more about job security with TypeScript over technical correctness and a robust implementation architecture and this shows the lack of it.
I’m a fan of Bubbletea, but it is significantly less ergonomic than React. Although I’d argue that if that starts to matter significantly, your TUI is probably too cluttered anyway and you should pare it down.
gemini-cli, opencode are also react based
Opencode uses SolidJS:
We moved from the go+bubbletea based TUI which had performance and capability issues to an in-house framework (OpenTUI) written in zig+solidjs
then maybe they should've bought and fixed Ink instead of bun, just saying!
FWIW, Ink is working on an incremental rendering system: they have a flag to enable it. It's currently pretty buggy though unfortunately. Definitely wish Anthropic would commit some resources back to the project they're built on to help fix it...
I have a hypothesis: they haven't fixed this because they're using Claude Code to develop Claude Code. I'm a fan of Claude Code, but it isn't good enough to fix tricky issues like this. And because no one looks at the codebase themselves, they haven't been able to fix it after many months. Sometimes, all we need is an engineer to sit down for the weekend and fix the damn bug, not spin up 9 different Claude Agents prompted to fix itself.
I think its clear the team is drowning. They are just trying to keep their head above water. They have massive adoption, high churn in the underlying models, and unlimited numbers of github issues opened every day.
Should it be solved by now? Yes. If anyone on the team is dogfooding it in a typical tmux environment, its painful. But lets give them some leeway here.
This is a massive commercial product with a serious issue (everyone knows about the flickering) that hasn't been solved for months now. I don't think leeway is warranted.
To your point, I’d say the dev team deserves some leeway, but the employer (Anthropic) is raking in the $$$ and doesn’t deserve any sympathy for underfunding the CC team.
Nobody is blaming the individual engineers here. The team as a whole can take the blame.
their web chat and app are also filled with bugs
> it’s because they don’t want people to see what a mess their code base is.
if Amodei hadn't said "90% of code will be written by AI", at least I wouldn't call them hypocrites, but the fact that the company that makes such wild claims can't fix a freaking flicker and scroll issue until an indie-dev steps in just shows how far behind their product is from their claims.
I have CC and use many models with it (Codex in CC, try it!), but I won't let Anthropic "lecture" us about how "the roots of the problem go deep". Literally no other CLI tool has these issues: opencode, codex, gemini, droid, etc.
I observe flickering with gemini-cli every now and then.
and it messes with tmux status bar for some reason.
The joke is that AGI will be achieved when Claude Code can fix the flickering in Claude Code.
Imagine the amount of slop PRs if it was open source. They don’t want to taste their own medicine
Reading their GitHub issues already is like reading through the diary entries of spurned lovers. I can only imagine the PRs.
I wouldn't be able to ship this to anyone without fixing it. Sending 5,000 lines of text to a terminal just to clear them all immediately, and in a loop... i'd be so embarrassed. Apps that clear scrollback have their uses, but you don't spam the terminal with unusable garbage.
And we solved this problem over 30 years ago? Ncurses was made for this. The buffer is kept in memory, you hit page-up and it renders the previous page, page-down and it renders the next page, let it roll and it renders each successive page as a stream, or just the last page, etc.
The biggest strength in OpenAI’s codex vs claude code is that it’s written in Rust and smooth as butter
except when it needs to do tasks then it's the slowest of them all
same, also it uses like 800M of ram... like why?
I would love to use this but it breaks Ghostty's native scrollback (two-finger scroll), which I want more than I want to solve the flickering. The PTY proxy intercepts the output stream so Ghostty can't access its internal scrollback buffer anymore.
Maybe try tmux? There’s no smooth scrolling, but there’s lots of other bells and whistles I wouldn’t give up for that.
Or even zellij > tmux
I wanted to believe, but wasn’t able to get most of my config working the same in zellij since it has fewer configuration knobs. Tried writing a plugin, but even those can’t touch much of the internal state. Particularly the keybinds I remember not being able to replicate (smart resizing, respecting vim, context sensitivity):
It is very 2026, that this exists for the product by a company that goes all in on vibe coding. Kudos for the creative solution.
I mentioned this to Claude and this was the response:
Ha! The irony is not lost on anyone.
"We've built the world's most advanced AI coding assistant. It can refactor entire codebases, debug complex issues, and ship production features autonomously. Anyway, here's a terminal bug that makes your screen look like a slot machine. We'll get to it eventually."
Not sure why you're being downvoted. Oh wait, I am, it's because this garbage doesn't work and nobody's allowed to point out that the emperor has no clothes. "We need the sum total of all capital on earth for our fancy Markov generator, and no, it doesn't redraw the screen properly."
One feature I'd love is a toggle to lock the input to the bottom of the terminal. It's a big inconvenience to have to scroll up and down between the chat and the input when responding to changes.
I was just thinking that half a hour ago when using Claude via tmux via mosh via my phone.
It would be a game changer for mobile usage.
The readme.md format and conventions being a tell that this got written by Claude Code itself makes the whole thing Chef's kiss. I love the future.
[deleted]
> this got written by Claude Code
nit but CC itself doesn't write anything, much like a body w/o brain doesn't program anything. it's possible the OP was using other models like codex/gemini/etc. in CC.
It's possible it's from some other model or even a human, but it reads like every other Claude Code readme I've seen.
so then it could be written by a claude model inside opencode before anthropic got angry about it :)
OpenCode still works fine with Claude models.
You just can’t use their private APIs, which isn’t really surprising.
There are workarounds on github already... It's less "can't" and more "they don't like it"
Thanks dang, but they didn't address the issue entirely and the scrolling issue still persists too.
Not implying the issue is closed...I just (<-- secret agenda) thought it was fun that the creator of Claude Code posted it :)
Haha, yeah it was CC's creator!
Possibly the greatest contribution to Claude code in months. I am rushing to my terminal to install, test, and update.
Codex is so much more responsive for me no matter how long the session is running. Claude just starts stuttering badly when the session is running for sometime.
Codex is written in Rust IIRC, probably makes a pretty big difference
THANK YOU! that flickering is giving me a headache. You're doing the lords work!
Anthropic: Please fix this ASAP
I don't know if this is my problem but formatting has been completely broken recently. It feels ... vibe coded. I wish they had not blocked opencode :(
Damn I had assumed it was that simple of a problem just based on how the scrolling messed up, and thought "surely it's not that simple"...
[deleted]
I initially thought this was by David Beazley, the python/rust guy.
I tried this in the cursor terminal and it now flickers periodically but not like crazy.
You are a legend. Thank you.
Excellent, thank you. This had be causing me headaches!
yeah its like im being hypnotized and im forced to wait until programming is over
just make the font-size smaller, and smaller, and smaller... until no more flickering.
Frustrating that the best agentic coding tool is such a bloated mess. I'm surprised they don't have a non-JS version ready for release.
Write it in Go!
Why didn't they just ask Claude to fix it?
I read the other day that one of their devs has a vanilla CC setup that consists of 10 agents running in parallel. Why doesn’t he just ask one of those agents to fix it??
amazing, thanks
Did this get written mostly by human hands, or did AI also write this? I would hope something like this was primarily made by humans...
Do you also write your bytecode by human hands? At which abstraction layer do we draw the line?
if it works then who cares?
An AI wrote it.
Why?
I guess it's not hard to use AI to improve your productivity by 10x when your code is written by 0.1x devs. It's embarrassing an OSS fixed their problem before they did after all that money they raised
Hi! I work on TUI rendering for Claude Code. I know this has been a long-standing frustration — it's taken longer than any of us wanted.
The good news: we shipped our differential renderer to everyone today. We rewrote our rendering system from scratch[1] and only ~1/3 of sessions see at least a flicker. Very, very few sessions see flickers in rapid succession which was so annoying before. Those numbers will keep dropping as people update.
We've also been working upstream to add synchronized output / DEC mode 2026 support to environments where CC runs and have had patches accepted to VSCode's terminal[2] and tmux[3]. Synchronized output totally eliminates flickering. As always, I recommend using Ghostty which has 2026 support and zero flicker.
Happy to answer questions!
[1]: https://github.com/anthropics/claude-code/issues/769#issueco... [2]: https://github.com/xtermjs/xterm.js/pull/5453 [3]: https://github.com/tmux/tmux/pull/4744
Why has public comms been so poor on this issue? There's been lots of Github issues posted in the Claude Code repo with lots of new comments each day screaming into the void, but radio silence from Anthropic since the revert in December. It's clearly causing a lot of frustration for users leading to clever workarounds like this.
It was obviously a complex issue (I appreciate that and your work!). But I think there's a lot to be improved on with communication. This issue in particular seems like it has lost a lot of user trust - not because it was hard to solve and took awhile - but because the comms and progress around it was so limited.
Eg issues: * https://github.com/anthropics/claude-code/issues/1913 * https://github.com/anthropics/claude-code/issues/826 * https://github.com/anthropics/claude-code/issues/3648
The communication is definitely on me! There honestly wasn't much new to say -I've been slowly ramping since early Jan just to be extra sure there's no regressions. The main two perf. issues were:
1. Since we no longer have <Static> components the app re-renders much more frequently with larger component trees. We were seeing unusual GC pauses because of having too much JSX... Better memoization has largely solved that. 2. The new renderer double buffers and blits similar cells between the front and back buffer to reduce memory pressure. However, we were still seeing large GC pauses from that so I ended up converting the screen buffer to packed TypedArrays.
I’m really surprised that GC is an issue at the bits/sec throughput a TUI would be pushing. At the risk of making an obvious observation: your render loop is doing way too much work for what it is producing.
I think this is the main issue. When I would get into flickering mode, it appeared that the entire TUI was re-rendering on every key press. I don’t know if it’s maybe just the limitation of Ink or even terminals.
Well vim doesn’t flicker so it’s definitely not a limitation of terminals, but you’re probably right about the Ink/React stack.
Have you guys seriously considered decoupling the TUI / UI so anyone can write their own on top of Claude Code proper? I love how Zed did it, but its not always the most stable experience, but it is definitely better than staring at a TUI.
Thanks for the update!
I believe the CC editor extensions and Zed's ACP both use the Claude Agent SDK.
Interesting, I'm only an end-user so I don't know too much about it, but the reason I ask is because of "OpenCode" or whatever it was called, that people were using instead of Claude Code itself, I figured if there was a way to make your own UI on top of Claude Code, surely OpenCode would have used it? Not sure whatever came of that whole fiasco. I never used OpenCode, but I like having the option to swap UIs as needed.
I wonder how much of Claude Code is developed using Claude?
A lot of it, and their Claude Cowork is all claude's work (according to claude code's creator).
> only ~1/3 of sessions see at least a flicker.
...after many months, for such a visible bug, is such a crazy thing to say.
In case the above comes across as too hostile, to balance this, I would say thank you to the claude code team for such an amazing product!
> The good news: we shipped our differential renderer to everyone today. We rewrote our rendering system from scratch[1] and only ~1/3 of sessions see at least a flicker. Very, very few sessions see flickers in rapid succession which was so annoying before. Those numbers will keep dropping as people update.
I'm using the latest version and see terrible flicker in tmux still. You guys should be ashamed tbh.
How tall is your tmux pane? If it's very small it might still flicker as CC tries to redraw scrollback. I've noticed several tmux users have layouts where they stack several panes on top of each other making each one quite short.
Another option is to rebuild tmux from latest source so it buffers synchronized output, which should prevent the flicker entirely.
If you're still seeing a terrible flicker please file a `/bug`!
Thanks for your response.
> How tall is your tmux pane? If it's very small it might still flicker as CC tries to redraw scrollback. I've noticed several tmux users have layouts where they stack several panes on top of each other making each one quite short.
It's full screen ("maximized" as tmux calls it).
> Another option is to rebuild tmux from latest source so it buffers synchronized output, which should prevent the flicker entirely.
I'll give it a shot.
I'm sorry for the low quality comment, but man, get some perspective.
> low quality comment
What else do you want me to say? It's ironic that one has to jump through hoops (like this post) to get basic functionality right in a tool that claims it'll replace software engineers.
Perspective is: how hard can it possibly be? It’s a TUI. This should be able to run on a calculator.
Am I missing some complexity here?
I have not used Claude Code in a couple months. THEY HAVEN’T FIXED THIS YET?
I’m starting to think that the reason why anthropic doesn’t open source Claude code isn’t due to competitive reasons, it’s because they don’t want people to see what a mess their code base is.
Maybe they bought Bun to increase the rate of flickering so that the text looks solid again
The problem is they are using the Ink library which clears and redraws for each update.
https://github.com/anthropics/claude-code/issues/769
I locally patched the closed-source CLI npm package but it's not perfect. They would have to switch how their TUI is rendered on their side.
Apparently OpenAI Codex is rust+ratatui which does not have this issue.
I'm always surprised that Python doesn't have as good TUI libraries as Javascript or Rust. With the amount of CLI tooling written in Python, you'd think it had better libraries than any other language.
Blessed was a decent one iirc:
https://github.com/jquast/blessed
One reason for the lack of python might be the timing of the TUI renaissance, which I think happened (is happening?) alongside the rise of languages like Go and Rust.
it has, but python being single threaded (until recently) didn't make it an attractive choice for CLI tools.
example: `ranger` is written in python and it's freaking slow. in comparison, `yazi` (Rust) has been a breeze.
Edit: Sorry, I meant GIL, not single thread.
> it has, but python being single threaded (until recently) didn't make it an attractive choice for CLI tools.
You probably mean GIL, as python has supported multi threading for like 20 years.
Idk if ranger is slow because it is written in python. Probably it is the specific implementation.
Even my CC status line script enjoyed a 20x speed improvement when I rewrote it from python to rust.
It’s surprising how quickly the bottleneck starts to become python itself in any nontrivial application, unless you’re very careful to write a thin layer that mostly shells out to C modules.
Textual looks really nice, but I usually make web apps so I haven’t tried it for anything serious:
https://textual.textualize.io/
Textual is A++. Feels a bit less snappy than Ink, but it makes up in all things with its immense feature-set. Seriously fun building apps of all kinds with this lib.
They started with Ink but have since switched to their own renderer:
> We originally built Claude Code on Ink, a React renderer for the terminal. [...] Over the past few months, we've rewritten our rendering system from scratch (while still using React).
https://github.com/anthropics/claude-code/issues/769#issueco...
Thanks for sharing. Very … interesting. Just trying to understand why the heck would React be the best tool here?
React is just an abstraction of a State -> View function.
While not universally applicable, it's very convenient during development to focus on State without thinking about View, or focus on View without thinking about State.
The concept itself has nothing to do with the actual renderer: HTML, TUI, or whatever. You can render your state to a text file if you want to.
So the flickering is caused either by a faulty renderer, or by using a render target (terminal) that is incompatible with the UI behavior (frequent partial re-renders, outputting a lot of text etc.)
I genuinely thought this was satire until I looked it up. I guess it's just to make us webdevs feel at home in the Terminal (ooh, spooky!)
React separates into layers.
Any web react project out there will install react AND react-dom, which is the son implementation of react.
It’s how react translates into mobile, web, etc so well.
It defines contracts and packages like react-dom handle th specific implementation.
Building a react renderer has long been on my wish list of weekend (>1 weekend most likely) projects.
Thats the problem. Some developers want to avoid learning another programming language and use one for everything (including their technologies.)
Using TS, React here doesn’t make sense for stability in the long term. As you can see, even when they replaced Ink and built their own, the problem still exists.
There are other alternatives that are better than whatever Anthropic did such as Bubbletea (Go) or Ratatui (Rust) which both are better suited for this.
Maybe they were thinking more about job security with TypeScript over technical correctness and a robust implementation architecture and this shows the lack of it.
I’m a fan of Bubbletea, but it is significantly less ergonomic than React. Although I’d argue that if that starts to matter significantly, your TUI is probably too cluttered anyway and you should pare it down.
gemini-cli, opencode are also react based
Opencode uses SolidJS:
https://opencode.ai/docs/1-0/React?!
Good grief get me off this sloppy ride.
then maybe they should've bought and fixed Ink instead of bun, just saying!
FWIW, Ink is working on an incremental rendering system: they have a flag to enable it. It's currently pretty buggy though unfortunately. Definitely wish Anthropic would commit some resources back to the project they're built on to help fix it...
I have a hypothesis: they haven't fixed this because they're using Claude Code to develop Claude Code. I'm a fan of Claude Code, but it isn't good enough to fix tricky issues like this. And because no one looks at the codebase themselves, they haven't been able to fix it after many months. Sometimes, all we need is an engineer to sit down for the weekend and fix the damn bug, not spin up 9 different Claude Agents prompted to fix itself.
I think its clear the team is drowning. They are just trying to keep their head above water. They have massive adoption, high churn in the underlying models, and unlimited numbers of github issues opened every day.
Should it be solved by now? Yes. If anyone on the team is dogfooding it in a typical tmux environment, its painful. But lets give them some leeway here.
This is a massive commercial product with a serious issue (everyone knows about the flickering) that hasn't been solved for months now. I don't think leeway is warranted.
Their GitHub issue tracker is very busy: https://github.com/anthropics/claude-code/pulse
To your point, I’d say the dev team deserves some leeway, but the employer (Anthropic) is raking in the $$$ and doesn’t deserve any sympathy for underfunding the CC team.
Nobody is blaming the individual engineers here. The team as a whole can take the blame.
their web chat and app are also filled with bugs
> it’s because they don’t want people to see what a mess their code base is.
if Amodei hadn't said "90% of code will be written by AI", at least I wouldn't call them hypocrites, but the fact that the company that makes such wild claims can't fix a freaking flicker and scroll issue until an indie-dev steps in just shows how far behind their product is from their claims.
I have CC and use many models with it (Codex in CC, try it!), but I won't let Anthropic "lecture" us about how "the roots of the problem go deep". Literally no other CLI tool has these issues: opencode, codex, gemini, droid, etc.
I observe flickering with gemini-cli every now and then.
and it messes with tmux status bar for some reason.
The joke is that AGI will be achieved when Claude Code can fix the flickering in Claude Code.
Imagine the amount of slop PRs if it was open source. They don’t want to taste their own medicine
Reading their GitHub issues already is like reading through the diary entries of spurned lovers. I can only imagine the PRs.
I wouldn't be able to ship this to anyone without fixing it. Sending 5,000 lines of text to a terminal just to clear them all immediately, and in a loop... i'd be so embarrassed. Apps that clear scrollback have their uses, but you don't spam the terminal with unusable garbage.
And we solved this problem over 30 years ago? Ncurses was made for this. The buffer is kept in memory, you hit page-up and it renders the previous page, page-down and it renders the next page, let it roll and it renders each successive page as a stream, or just the last page, etc.
The biggest strength in OpenAI’s codex vs claude code is that it’s written in Rust and smooth as butter
except when it needs to do tasks then it's the slowest of them all
same, also it uses like 800M of ram... like why?
I would love to use this but it breaks Ghostty's native scrollback (two-finger scroll), which I want more than I want to solve the flickering. The PTY proxy intercepts the output stream so Ghostty can't access its internal scrollback buffer anymore.
Maybe try tmux? There’s no smooth scrolling, but there’s lots of other bells and whistles I wouldn’t give up for that.
Or even zellij > tmux
I wanted to believe, but wasn’t able to get most of my config working the same in zellij since it has fewer configuration knobs. Tried writing a plugin, but even those can’t touch much of the internal state. Particularly the keybinds I remember not being able to replicate (smart resizing, respecting vim, context sensitivity):
https://github.com/foltik/dots/blob/main/config/tmux.conf
It is very 2026, that this exists for the product by a company that goes all in on vibe coding. Kudos for the creative solution.
I mentioned this to Claude and this was the response:
Ha! The irony is not lost on anyone.
"We've built the world's most advanced AI coding assistant. It can refactor entire codebases, debug complex issues, and ship production features autonomously. Anyway, here's a terminal bug that makes your screen look like a slot machine. We'll get to it eventually."
Not sure why you're being downvoted. Oh wait, I am, it's because this garbage doesn't work and nobody's allowed to point out that the emperor has no clothes. "We need the sum total of all capital on earth for our fancy Markov generator, and no, it doesn't redraw the screen properly."
One feature I'd love is a toggle to lock the input to the bottom of the terminal. It's a big inconvenience to have to scroll up and down between the chat and the input when responding to changes.
I was just thinking that half a hour ago when using Claude via tmux via mosh via my phone.
It would be a game changer for mobile usage.
The readme.md format and conventions being a tell that this got written by Claude Code itself makes the whole thing Chef's kiss. I love the future.
> this got written by Claude Code
nit but CC itself doesn't write anything, much like a body w/o brain doesn't program anything. it's possible the OP was using other models like codex/gemini/etc. in CC.
It's possible it's from some other model or even a human, but it reads like every other Claude Code readme I've seen.
so then it could be written by a claude model inside opencode before anthropic got angry about it :)
OpenCode still works fine with Claude models.
You just can’t use their private APIs, which isn’t really surprising.
There are workarounds on github already... It's less "can't" and more "they don't like it"
Oh my god who cares?
Related (I think?):
We've rewritten Claude Code's terminal rendering to reduce flickering by 85% - https://news.ycombinator.com/item?id=46312507 - Dec 2025 (3 comments)
Thanks dang, but they didn't address the issue entirely and the scrolling issue still persists too.
Not implying the issue is closed...I just (<-- secret agenda) thought it was fun that the creator of Claude Code posted it :)
Haha, yeah it was CC's creator!
Possibly the greatest contribution to Claude code in months. I am rushing to my terminal to install, test, and update.
Codex is so much more responsive for me no matter how long the session is running. Claude just starts stuttering badly when the session is running for sometime.
Codex is written in Rust IIRC, probably makes a pretty big difference
THANK YOU! that flickering is giving me a headache. You're doing the lords work!
Anthropic: Please fix this ASAP
I don't know if this is my problem but formatting has been completely broken recently. It feels ... vibe coded. I wish they had not blocked opencode :(
Damn I had assumed it was that simple of a problem just based on how the scrolling messed up, and thought "surely it's not that simple"...
I initially thought this was by David Beazley, the python/rust guy.
I tried this in the cursor terminal and it now flickers periodically but not like crazy.
You are a legend. Thank you.
Excellent, thank you. This had be causing me headaches!
yeah its like im being hypnotized and im forced to wait until programming is over
just make the font-size smaller, and smaller, and smaller... until no more flickering.
Frustrating that the best agentic coding tool is such a bloated mess. I'm surprised they don't have a non-JS version ready for release.
Write it in Go!
Why didn't they just ask Claude to fix it?
I read the other day that one of their devs has a vanilla CC setup that consists of 10 agents running in parallel. Why doesn’t he just ask one of those agents to fix it??
amazing, thanks
Did this get written mostly by human hands, or did AI also write this? I would hope something like this was primarily made by humans...
Do you also write your bytecode by human hands? At which abstraction layer do we draw the line?
if it works then who cares?
An AI wrote it.
Why?
I guess it's not hard to use AI to improve your productivity by 10x when your code is written by 0.1x devs. It's embarrassing an OSS fixed their problem before they did after all that money they raised