Claude Chill: Fix Claude Code's flickering in terminal

2026-01-2023:26192148github.com

Contribute to davidbeesley/claude-chill development by creating an account on GitHub.

CI License: MIT Linux macOS Windows Rust

A PTY proxy that tames Claude Code's massive terminal updates using VT-based rendering.

Claude Code uses synchronized output to update the terminal atomically. It wraps output in sync markers (\x1b[?2026h ... \x1b[?2026l) so the terminal renders everything at once without flicker.

The problem: Claude Code sends entire screen redraws in these sync blocks - often thousands of lines. Your terminal receives a 5000-line atomic update when only 20 lines are visible. This causes lag, flicker, and makes scrollback useless since each update clears history.

claude-chill sits between your terminal and Claude Code:

  1. Intercepts sync blocks - Catches those massive atomic updates
  2. VT-based rendering - Uses a VT100 emulator to track screen state and renders only the differences
  3. Preserves history - Accumulates content in a buffer for lookback
  4. Enables lookback - Press a key to pause Claude and view the full history buffer
cargo install --path crates/claude-chill
claude-chill claude
claude-chill -- claude --verbose # Use -- for command flags
$ claude-chill --help
A PTY proxy that tames Claude Code's massive terminal updates

Usage: claude-chill [OPTIONS] <COMMAND> [ARGS]...

Arguments:
  <COMMAND>  Command to run (e.g., "claude")
  [ARGS]...  Arguments to pass to the command

Options:
  -H, --history <HISTORY_LINES>
          Max lines stored for lookback (default: 100000)
  -k, --lookback-key <LOOKBACK_KEY>
          Key to toggle lookback mode, quote to prevent glob expansion (default: "[ctrl][6]")
  -a, --auto-lookback-timeout <AUTO_LOOKBACK_TIMEOUT>
          Auto-lookback timeout in ms, 0 to disable (default: 5000)
  -h, --help
          Print help
  -V, --version
          Print version
# Basic usage
claude-chill claude # Pass arguments to claude
claude-chill -- claude --verbose # Custom history size
claude-chill -H 50000 claude # Custom lookback key
claude-chill -k "[f12]" claude # Disable auto-lookback (see below)
claude-chill -a 0 claude # Combine options with claude arguments
claude-chill -H 50000 -a 0 -- claude --verbose

Press Ctrl+6 (or your configured key) to enter lookback mode:

  1. Claude pauses - Output from Claude is cached, input is blocked
  2. History dumps - The full history buffer is written to your terminal
  3. Scroll freely - Use your terminal's scrollback to review everything
  4. Exit - Press the lookback key again or Ctrl+C to resume

When you exit lookback mode, any cached output is processed and the current state is displayed.

After 5 seconds of idle (no new renders), the full history is automatically dumped to your terminal so you can scroll back without pressing any keys. This is useful for reviewing Claude's output after it finishes working.

Note: The auto-lookback causes a brief screen flicker during the transition as it clears the screen and writes the history buffer. Disable with -a 0 or adjust the timeout with -a 10000 (10 seconds).

Create ~/.config/claude-chill.toml:

history_lines = 100000 # Max lines stored for lookback
lookback_key = "[ctrl][6]" # Key to toggle lookback mode
refresh_rate = 20 # Rendering FPS
auto_lookback_timeout_ms = 5000 # Auto-lookback after 5s idle (0 to disable)

Note: History is cleared on full screen redraws, so lookback shows output since Claude's last full render.

[modifier][key] - Examples: [f12], [ctrl][g], [ctrl][shift][j]

Modifiers: [ctrl], [shift], [alt]

Keys: [a]-[z], [f1]-[f12], [pageup], [pagedown], [home], [end], [enter], [tab], [space], [esc]

Note: Quote the key value on the command line to prevent shell glob expansion: -k "[ctrl][7]"

Ctrl+6 sends 0x1E, a control character not frequently used by terminals, signals, or shells. Avoid Ctrl+letter hotkeys - terminals can't distinguish Ctrl+J from Ctrl+Shift+J.

claude-chill creates a pseudo-terminal (PTY) and spawns Claude Code as a child process. It then acts as a transparent proxy between your terminal and Claude:

┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│   Terminal   │◄───►│ claude-chill │◄───►│  Claude Code │
│   (stdin/    │     │   (proxy)    │     │   (child)    │
│    stdout)   │     │              │     │              │
└──────────────┘     └──────────────┘     └──────────────┘
  1. Input handling: Keystrokes pass through to Claude, except for the lookback key which toggles lookback mode
  2. Output processing: Scans output for sync block markers. Non-sync output passes through directly
  3. VT emulation: Feeds output through a VT100 emulator to track the virtual screen state
  4. Differential rendering: Compares current screen to previous and emits only the changes
  5. History tracking: Maintains a buffer of output for lookback mode since the last full redraw
  6. Signal forwarding: Window resize (SIGWINCH), interrupt (SIGINT), and terminate (SIGTERM) signals are forwarded to Claude

This tool was developed for personal convenience. It works for me on Linux and macOS, but it hasn't been extensively tested across different terminals or edge cases. Don't use it to send anyone to space, perform surgery, or run critical infrastructure. If it breaks, you get to keep both pieces.

See CONTRIBUTING.md.

MIT


Read the original article

Comments

  • By chrislloyd 2026-01-214:1112 reply

    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

    • By elliot07 2026-01-214:302 reply

      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

      • By chrislloyd 2026-01-215:001 reply

        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.

        • By catlifeonmars 2026-01-216:222 reply

          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.

          • By chrislloyd 2026-01-2114:185 reply

            Most people's mental model of CC is that "it's just a TUI" but it should really be closer to "a small game engine". For each frame our pipeline constructs a scene graph with React -> layout elements -> rasterize them to a 2d screen -> diff that against the previous screen -> _finally_ use the diff to generate ANSI sequences to draw. We have a ~16ms frame budget so we have roughly ~5ms to go from the React scene graph to ANSI written. You're right that in theory we shouldn't have to do much work, but in practice that's required optimizations at every step.

            For the GC pauses specifically, what mattered is predictable performance. More allocations == more GC == more frames where the VM is locked up seemingly doing nothing. On slower machines we were seeing this be in the order of seconds, not ms and when somebody is typing all they feel is the 1 character that's stuttering. Honestly, I was surprised about this too as GC in JS is often not something that's too impactful.

            • By vintagedave 2026-01-229:271 reply

              Can I ask why you used JavaScript at all for CC? Or even React for a simple UI? It seems misaligned with the app’s nature. This bug, GC pauses, everything else you mention… This isn’t criticism, because I believe people make good judgements and you and Anthropic will have good reasons! It’s just puzzlement, in that I don’t understand what the balance judgement was that led you here, and having experienced all the issues it led to I would love to know what the reasons were. Thankyou for any insights you can share :)

              • By eyeris 2026-01-231:241 reply

                Supposedly using react allows CC to have structured output so it can understand what’s on the screen.

            • By brazukadev 2026-01-2117:21

              Maybe the problem is using React for that.

            • By catlifeonmars 2026-01-226:07

              Thanks for the in depth explanation! I think the comparison to a game engine makes a lot of sense. Is the diff just part of the react rendering engine, or is it something you intentionally introduce as a performance optimization? Mostly I’m wondering how much the diff saves on rendering performance if you’ve already generated a 2D raster. In the browser, this saves on API calls to the DOM but at that point you haven’t rendered anything resembling an image. Is this what helps to resolve flickering, perhaps?

            • By withinboredom 2026-01-2222:29

              > On slower machines we were seeing this be in the order of seconds, not ms and when somebody is typing all they feel is the 1 character that's stuttering.

              You mean like a laptop that is trying to stay cool (aka, cpu throttling) on battery power while Claude is running a slightly different version of the test suite for the 5th time to verify it didn't break anything?

              Yeah, the typing latency is really bad in those cases. Sometimes waiting for 40 seconds or more.

            • By xyzsparetimexyz 2026-01-2210:082 reply

              What the fuck? What's wrong with idk, ncurses?

              • By pennomi 2026-01-2213:311 reply

                TUI development is a lost art these days, apparently.

                • By catlifeonmars 2026-01-2215:07

                  TUIs are experiencing something of a renaissance, I think. My hypothesis is that the popularity attracts newcomers who inevitably bring their own preconceptions from other domains. Many are unaware of the state of the art and reinvent the wheel. I don’t think this categorically a bad thing, but it can be a mixed bag of slop and genuinely useful cross-pollination.

              • By justinhj 2026-01-2317:04

                Code sharing with their web app. Layouts. Event handling. Not wanting to reimplement all that from scratch when React and Ink is a popular and full featured option.

          • By moltar 2026-01-217:331 reply

            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.

            • By catlifeonmars 2026-01-217:491 reply

              Well vim doesn’t flicker so it’s definitely not a limitation of terminals, but you’re probably right about the Ink/React stack.

      • By pqtyw 2026-01-2518:01

        Presumably they had no clue how to fix it and just ignored it and pretended everything works fine because they didn't want to admit it?

    • By rovr138 2026-01-2115:41

      On the Ghostty recommendation, read this first - https://mitchellh.com/writing/ghostty-memory-leak-fix

      > A few months ago, users started reporting that Ghostty was consuming absurd amounts of memory, with one user reporting 37 GB after 10 days of uptime.

      > ...

      > The leak was present since at least Ghostty 1.0, but it is only recently that popular CLI applications (particularly Claude Code) started producing the correct conditions to trigger it at scale. The limited conditions that triggered the leak are what made it particularly tricky to diagnose.

      > The fix is merged and is available in tip/nightly releases, and will be part of the tagged 1.3 release in March.

    • By giancarlostoro 2026-01-215:211 reply

      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!

      • By chrislloyd 2026-01-215:361 reply

        I believe the CC editor extensions and Zed's ACP both use the Claude Agent SDK.

        • By giancarlostoro 2026-01-217:191 reply

          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.

          • By embedding-shape 2026-01-219:111 reply

            > I figured if there was a way to make your own UI on top of Claude Code, surely OpenCode would have used it?

            Besides the UI, it isn't much more than "while llm hasn't made final response, interpret any tool calls and repeat" to the current agents, what exactly would they be using from Claude Code if not the UI? Most of the stuff the agents do is fairly basic, implementation-wise.

            • By giancarlostoro 2026-01-2114:241 reply

              Sure but that doesn't explain why OpenCode was basically barred from using Claude Code.

              • By embedding-shape 2026-01-2115:12

                Why would they need to use Claude Code? If you're building your own thing, why would you have to use your "competitors" thing to build you own thing? Something doesn't make sense there.

                Besides the point, but I hadn't heard about that. I take it's about this? https://news.ycombinator.com/item?id=46625918, if so, seems to been reasonable since OpenCode was trying to use endpoints not meant for them?

                > They’ve blocked OpenCode from accessing the private Claude Code endpoints. These were not advertised or sold as usable with anything else. OpenCode reverse engineered the API and was trying to use it.

    • By pmarreck 2026-01-2215:49

      While I have you on the line, I'm also experiencing tons of API request timeouts using Claude Code's own TUI client (on the $200/mo plan!!) and I don't know how to mitigate that, and it is frustrating

      I'm not even using it particularly hard. Usually only one agent is running with possibly one sub-agent on occasion. Which is confusing because I've heard of people running ten at once and only then running into this issue...

      Possibly related, I DID only upgrade to the $200 tier a few days ago... might there be a now-stale API rate limit in place?? Or maybe it's the long-running multi-compacted context that's the problem?

      My account is tied to lumbergh-at-gmail-dot-com

      I'm a dev so of course, happy to help run it down from my end

      This tool is amazing btw. I'm currently working on a never-existed-before app that would have been impossible before AI... And it's going quite well

    • By badlogic 2026-01-2111:04

      > differential rendering

      Now where have I seen that before.

    • By pqtyw 2026-01-2518:00

      > and only ~1/3 of sessions see at least a flicker

      Sounds like only is a bit misplaced. IMHO such bugs that take forever to fix make Anthropic seem very unprofessional.

    • By victor106 2026-01-215:011 reply

      I wonder how much of Claude Code is developed using Claude?

      • By behnamoh 2026-01-215:111 reply

        A lot of it, and their Claude Cowork is all claude's work (according to claude code's creator).

        • By shepherdjerred 2026-01-223:15

          after trying out Claude Cowork, I can definitely believe it was vibe coded

    • By redrove 2026-01-2220:34

      Can you guys give this some love? https://github.com/anthropics/claude-code/issues/769

      I had to use Codex today cause claude kept scrolling up every time the window lost focus. It was so annoying. macOS iTerm

    • By xcodevn 2026-01-214:361 reply

      > 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!

      • By embedding-shape 2026-01-218:131 reply

        More than 30% of the times you use Claude Code it "flickers"? That can't be right? I use neovim and codex side by side with tmux, both flicker about 0%, what is Claude Code doing that makes it flicker so much? Seems strange

        • By chrislloyd 2026-01-2114:371 reply

          (It's worth reading the gh comment I linked if you're interested in terminals!)

          tl;dr other programs like Neovim and Codex use the "alternate screen buffer" which means they don't use scrollback and reimplement their own scrolling. CC uses scrollback (because that's what most users expect) which it has to clear entirely and redraw everything when it changes (causing tearing/flickering). There's no way to incrementally update scrollback in a terminal.

          (I also want to add some more flavor to the 1/3 metric because I don't want it to be mis-interpreted. "30% of the time you use CC it flickers" isn't quite accurate - it's dependent on screen height and what you do. Most people will not see _any_ flickers at all. Some people with short screens (typically VSCode users because by default the terminal opens fairly short) will see flickers. Previously, if something rendered offscreen users would see a flicker for _every subsequent frame_ regardless of wether anything was actually changing. Now they will only see a flicker occasionally when it's _absolutely_ needed. Once or twice vs thousands.

          Additionally, the metric really tracks when CC emits a "clear scrollback" operation. If the user is in a terminal that supports DEC 2026 they won't see a flicker even if we emit that clear scrollback command.)

          • By withinboredom 2026-01-229:13

            There is absolutely a way to incrementally update scrollback in a terminal, 100% flicker-free. Whether it works in every terminal is a different question. But if you can accept that your code will work in pretty much every modern terminal -- this is absolutely doable. I double people are still using xterm and other older terminals for this. And in that case, you can fall back to this more compatible way.

    • By psyclobe 2026-01-2217:28

      Seeing massive slowdowns in console interactions today... is there a correlation? Others here at my work are seeing it too!

    • By behnamoh 2026-01-215:102 reply

      > 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.

      • By chrislloyd 2026-01-215:291 reply

        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`!

        • By behnamoh 2026-01-215:45

          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.

      • By corndoge 2026-01-215:134 reply

        I'm sorry for the low quality comment, but man, get some perspective.

        • By behnamoh 2026-01-215:43

          > 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.

        • By catlifeonmars 2026-01-215:561 reply

          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?

          • By pennomi 2026-01-2213:351 reply

            It’s really hard, because they’re trying to use a hammer as a hacksaw. It was simply made with ridiculous technology choices.

            • By catlifeonmars 2026-01-2215:13

              I think you described 99% of commercial software :)

        • By pqtyw 2026-01-2518:05

          Well it's for profit company and a closed code app. How cares about "hurting their feeling" or whatever? Harsh criticism seems perfectly appropriate here...

        • By gbin 2026-01-2211:47

          This seems stupid but after evaluating Claude vs Codex, this problem alone made me pick Codex.

          If I cannot follow what the thing is doing the tool becomes useless and expensive.

          I use Kitty + zellij, I love TUIs and use them all over the place, this is the only tool I know with this issue.

    • By pmarreck 2026-01-2215:34

      i’ve noticed the issue with tmux more than with specific terminals.

      basically, the rapid replay of the entire conversation history (the CC bug) somehow interacts destructively with something in tmux, causing it to be 10 times worse. The “flicker” becomes a multi-second delay while I wait twiddling my thumbs…

      i’ve seen this in every terminal, including ghostty… as nice as ghostty is, expecting everyone to use it is kinda meh (at least support Wezterm too, lol)

  • By prodigycorp 2026-01-211:189 reply

    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

    • By EMM_386 2026-01-211:433 reply

      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.

      • By thomasahle 2026-01-212:004 reply

        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.

        • By wonger_ 2026-01-212:54

          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.

        • By behnamoh 2026-01-212:021 reply

          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.

          • By ashirviskas 2026-01-212:152 reply

            > 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.

            • By embedding-shape 2026-01-219:12

              > You probably mean GIL

              They also probably mean TUIs, as CLIs don't do the whole "Draw every X" thing (and usually aren't interactive), that's basically what sets them apart from CLIs.

            • By behnamoh 2026-01-213:481 reply

              Even my CC status line script enjoyed a 20x speed improvement when I rewrote it from python to rust.

              • By foltik 2026-01-215:12

                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.

        • By acdha 2026-01-212:352 reply

          Textual looks really nice, but I usually make web apps so I haven’t tried it for anything serious:

          https://textual.textualize.io/

          • By thomasahle 2026-01-223:42

            Textual is cook, but it's maintained by a single guy, and the roadmap hasn't been updated since 2023, https://textual.textualize.io/roadmap/

          • By sibeliuss 2026-01-213:57

            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.

        • By blks 2026-01-2110:55

          I’m using Textual for my TUI needs, it’s very decent.

      • By jschlatter 2026-01-212:152 reply

        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...

        • By cududa 2026-01-212:175 reply

          Thanks for sharing. Very … interesting. Just trying to understand why the heck would React be the best tool here?

          • By zlumer 2026-01-213:12

            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.)

          • By rvz 2026-01-212:321 reply

            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.

            • By catlifeonmars 2026-01-216:11

              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.

          • By anematode 2026-01-212:28

            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!)

          • By Atotalnoob 2026-01-213:581 reply

            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.

            • By catlifeonmars 2026-01-216:09

              Building a react renderer has long been on my wish list of weekend (>1 weekend most likely) projects.

          • By guluarte 2026-01-213:411 reply

            gemini-cli, opencode are also react based

            • By esafak 2026-01-216:08

              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
              
              https://opencode.ai/docs/1-0/

        • By lifetimerubyist 2026-01-212:44

          React?!

          Good grief get me off this sloppy ride.

      • By behnamoh 2026-01-211:441 reply

        then maybe they should've bought and fixed Ink instead of bun, just saying!

        • By reissbaker 2026-01-212:11

          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...

    • By xcodevn 2026-01-213:162 reply

      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.

      • By profunctor 2026-01-2215:40

        Perhaps the engineer could sit down for 8 hours a day during the work week. The Silicon Valley obsession with having no life and working weekends is so endemic.

      • By wetpaws 2026-01-228:29

        [dead]

    • By behnamoh 2026-01-211:331 reply

      > 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.

      • By Xmd5a 2026-01-212:451 reply

        I observe flickering with gemini-cli every now and then.

        • By behnamoh 2026-01-213:48

          and it messes with tmux status bar for some reason.

    • By JamesSwift 2026-01-212:515 reply

      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.

      • By jjayj 2026-01-213:07

        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.

      • By catlifeonmars 2026-01-216:141 reply

        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.

        • By JamesSwift 2026-01-223:471 reply

          Do you suggest hiring 1000 extra devs to close the issues? At some point, it doesnt actually scale. Whos to say they havent hit that limit already?

          • By catlifeonmars 2026-01-229:521 reply

            Funding doesn’t _necessarily_ mean hiring more devs.

            To your point about hiring 1000 devs not solving anything: I agree. For a project of this scope, you’re probably going to peak at one or two 3 person teams with at least one principal dev per team with deep experience in the tech stack and in architecting/building TUIs in general. I would hope their devs are making a relatively lucrative salary too, to attract talent.

            I have no idea what the internal structure is so this is just pure speculation: judging by the backlog of issues on their GH, they could use better community management and developer relations. I suspect they’re riding on the existing hype/community interest to fulfill these functions but that only provides a piece of the puzzle.

            • By JamesSwift 2026-01-2215:18

              > For a project of this scope, you’re probably going to peak at one or two 3 person teams with at least one principal dev per team

              I think thats probably 1 team short, but I agree on the order of magnitude. So if we assume 12 devs, how long do we think its going to take to fix 5k github issues lol?

              Again, I 100% agree the flicker bug should be at the top of the list. And I agree their products in general are riddled with bugs. But Im just saying I can understand the situation even if I think this specific bug should have been fixed already if they were regularly using a setup that runs into it (which I have to assume they arent).

      • By dymk 2026-01-213:36

        Nobody is blaming the individual engineers here. The team as a whole can take the blame.

      • By esafak 2026-01-216:11

        Their GitHub issue tracker is very busy: https://github.com/anthropics/claude-code/pulse

      • By guluarte 2026-01-213:461 reply

        their web chat and app are also filled with bugs

        • By JamesSwift 2026-01-223:48

          100% agree their products have tons of bugs. Im not defending the quality, Im saying I understand the situation.

    • By artursapek 2026-01-212:011 reply

      The biggest strength in OpenAI’s codex vs claude code is that it’s written in Rust and smooth as butter

      • By aixpert 2026-01-213:54

        except when it needs to do tasks then it's the slowest of them all

    • By bottlepalm 2026-01-212:57

      The joke is that AGI will be achieved when Claude Code can fix the flickering in Claude Code.

    • By guluarte 2026-01-213:19

      same, also it uses like 800M of ram... like why?

    • By 0xbadcafebee 2026-01-213:511 reply

      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.

      • By teknologist 2026-01-246:36

        Many users do like to use scrollback to copy large passages of text, which becomes difficult and cumbersome if they have to use page-up page-down to get at the other parts of it.

    • By f311a 2026-01-211:281 reply

      Imagine the amount of slop PRs if it was open source. They don’t want to taste their own medicine

      • By prodigycorp 2026-01-211:29

        Reading their GitHub issues already is like reading through the diary entries of spurned lovers. I can only imagine the PRs.

  • By benzible 2026-01-211:442 reply

    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.

    • By bmurphy1976 2026-01-223:101 reply

      How does Ghostty break scroll? I've never noticed this and I just tested, seems to work fine. My problem is the lack of a scrollbar but I know they are working on that.

      • By benzible 2026-01-2314:16

        This is a thread about Claude Chill. I said that Claude Chill breaks scrollback on ghostty.

    • By foltik 2026-01-212:131 reply

      Maybe try tmux? There’s no smooth scrolling, but there’s lots of other bells and whistles I wouldn’t give up for that.

      • By thethimble 2026-01-213:531 reply

        Or even zellij > tmux

        • By foltik 2026-01-215:09

          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

HackerNews