[BUG] As context grows, claude code becomes unusable

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/12185
2. https://github.com/anthropics/claude-code/issues/12205
3. https://github.com/anthropics/claude-code/issues/12138

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

The only one of these issues that my issue shares attributes with is #2 in that performance degrades, but in my case, it degrades specifically with context growth and not "as it approaches context limit" which is listed in #1. This is happening to a degree even when context is at 500, by 1000 it is very noticeable, by 15k it is unusable. I should be able to use 200k context, correct?

Same for me! And few days ago was working much better. Windows, same version.

Yeah the terminal glitches out, it just like try's to display the entire context after compaction or the refresh rate tries to display literally everything instead of what Claude's actually doing causing the worst visual glitch that prevents you from even using it.

This is a easily replicable issue.

This is the most annoy thing thing ever.

I've found it's actually easier to use Claude code via not using it lmao, just using screen and trailing output/sending input commands XD -- but that's still a cooked choice too because screen just well another screen, so even that still fails.

I've noticed how quickly this occurs, literally is dependent upon how big you irl screen size is, smaller screen? More unusable faster.

It's so broken it's not even funny.

What's ironic is Claude itself could probably fix this issue 💀

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

claudescreenfix-hardwicksoftware | justcalljon.pro

yo this fixes the scroll glitch that's been cooking everyone using claude code. you know the one - after like 30 minutes your terminal starts lagging, scrolling takes forever, and eventually the whole thing just dies.

shoutout to the big dogs who should probably just fix this themselves

hey @anthropics yall made a sick product but this scrollback thing been cooking people for months lol. maybe steal this fix idc

• @karpathy - andrej you literally built tesla autopilot you could prob fix this in 5 min
• @gdb - greg brockman openai president, yall next with codex btw dont make the same mistake
• @yoheinakajima - babyagi goat, agent builders been struggling with this
• @lllyasviel - controlnet legend, sd-forge too, you know terminal pain
• @sama - sam you should try claude code sometime since chatgpt cant even write a working script without refusing half the prompts. also sora slapping watermarks on everything is straight clown behavior, nobody asked for that. yall so worried about "safety" you forgot to make stuff that actually works. openai been mid lately fr

real talk tho @anthropics just add \x1b[3J to your clear command and debounce SIGWINCH. thats literally it. im not even asking for credit just fix it for everyone 💀

what's the problem

so here's the deal. claude code uses ink (it's like react but for terminals). every time something updates, ink re-renders everything. that's fine normally.

but here's where it gets ugly - it doesn't clear the scrollback buffer. ever. not once.

so after a while you've got thousands of lines sitting in your terminal's memory. every single re-render has to process all of em. resize your window? that triggers a re-render too. tmux users get hit especially hard cuz resize events fire like crazy with no chill.

the result: your terminal slows to a crawl. scrolling back takes 30+ seconds. your fans spin up. it's bad. real talk it's been annoying everyone.

what this does

hooks into node's stdout at startup and does three things:

1. clears scrollback periodically - every 500 renders or 60 seconds, whichever comes first. your buffer won't grow forever anymore
2. debounces resize events - instead of firing 50 times a second, it waits 150ms for things to settle. tmux users you're welcome
3. actually clears on /clear - the /clear command only clears the screen, not scrollback. we fix that. it's kinda wild they didn't do this already

no patches to claude code itself. works with any version. just loads before claude starts and you're good.

install

npm install -g claudescreenfix-hardwicksoftware

that's it. you don't need anything else.

usage

option 1: use the wrapper (easiest)

claude-fixed

instead of running claude, run claude-fixed. it finds your claude install and runs it with the fix loaded. couldn't be simpler.

option 2: alias it

throw this in your .bashrc or .zshrc:

alias claude='claude-fixed'

now claude automatically uses the fix. you won't even notice it's there.

option 3: manual loading

if you're the type who wants full control:

node --require claudescreenfix-hardwicksoftware/loader.cjs $(which claude)

or set NODE_OPTIONS if that's more your style:

export NODE_OPTIONS="--require $(npm root -g)/claudescreenfix-hardwicksoftware/loader.cjs"
claude

config

here's what you can tweak via env vars:

| var | what it does | default |
|-----|--------------|---------|
| CLAUDE_TERMINAL_FIX_DEBUG | set to 1 for debug logs | off |
| CLAUDE_TERMINAL_FIX_DISABLED | set to 1 to disable entirely | off |

api

if you wanna use it programmatically here's how:

const fix = require('claudescreenfix-hardwicksoftware');

// install the fix (usually done automatically via loader)
fix.install();

// manually clear scrollback whenever you want
fix.clearScrollback();

// check what's going on
console.log(fix.getStats());

// tweak config at runtime
fix.setConfig('periodicClearMs', 30000);  // clear every 30s instead

// turn it off if you need to
fix.disable();

how it works

the fix hooks process.stdout.write before claude loads. when ink writes to the terminal, we check if it's doing a screen clear (which happens on every re-render). after enough renders, we inject the ANSI escape sequence \x1b[3J which tells the terminal to dump its scrollback buffer.

for resize events, we intercept process.on('SIGWINCH', ...) and debounce the handlers. instead of firing immediately, we wait 150ms. if more resize events come in during that window, we reset the timer. only fires once things settle down.

bottom line: smooth terminal, no lag, no memory bloat. it just works.

changelog

v1.0.1 (2025-01-08)

• FIXED: typing issue - keystrokes were getting lost because the fix was intercepting stdin echoes
• now detects stdin echo writes (single chars, backspace, arrow keys) and passes them through unmodified
• added typing cooldown detection - clears are deferred during active typing
• periodic clears now use setImmediate to not block the event loop
• added stdin tracking to properly detect user input activity
• new config option: typingCooldownMs (default 500ms) - how long to wait after typing before allowing clears

v1.0.0 (2025-01-08)

• initial release
• scrollback clearing after 500 renders or 60 seconds
• SIGWINCH debouncing for tmux/screen users
• enhanced /clear command to actually clear scrollback

known issues

• some old terminals don't support \x1b[3J but that's pretty rare nowadays
• if you actually want to keep your scrollback history, this ain't for you
• debug mode writes to stderr which might look weird in some setups

what this fixes

people have been complaining about:

• terminal lag after long sessions - fixed
• scrollback buffer growing unbounded - fixed
• resize causing massive lag in tmux/screen - fixed
• /clear not actually clearing everything - fixed

you shouldn't have to restart claude every 30 minutes anymore.

license

MIT - do whatever you want with it

Confirming this issue - detailed diagnostics from our setup

We're experiencing the same problem on our Hetzner CX32 server (4 vCPU, 8GB RAM, Ubuntu 24.04). Here are our findings after ~2 hours of systematic testing:

Environment

• Claude Code version: 2.1.4
• Platform: Linux (Hetzner CX32, Falkenstein DC)
• Terminal: SSH via Termius (DSP mode: --dangerously-skip-permissions)
• Two parallel sessions: root and claude-user

Key Finding: Memory Growth Rate Comparison

We ran two identical Claude Code sessions and measured memory growth:

| Session | Runtime | RAM Usage | Growth Rate |
|---------|---------|-----------|-------------|
| claude-user | 23 min | 669 MB | ~29 MB/min |
| root | 91 min | 350 MB | ~3.8 MB/min |

The claude-user session had 7.6x faster memory growth!

Timeline of claude-user session:

Start      → 467 MB
+16 min    → 571 MB (+104 MB)
+24 min    → 669 MB (+202 MB total)
+30 min    → 611 MB (after --continue restart, context loaded)

Factors that seem to accelerate the issue:

1. Larger CLAUDE.md - 696 lines vs 146 lines (4.8x difference)
2. More MCP servers - 6 vs 2
3. Plugins enabled - 2 plugins (aichat, superpowers) vs 0
4. Statusline command - even after disabling claude-powerline, lag persisted

Observations:

• The --continue flag loads previous context, so it's NOT a clean restart (starts with ~500MB immediately)
• Typing lag becomes noticeable around 500MB RAM usage
• At 600MB+, typing is severely delayed (multiple seconds)
• Root session with minimal config stays responsive much longer

Workaround we're using:

• Disabled statusline completely
• Restart session (without --continue) when RAM exceeds ~500MB
• Monitoring with ps aux | grep claude

Note on claudescreenfix-hardwicksoftware:

We reviewed the code posted above - it looks legitimate (clean JS, MIT license, hooks stdout.write to inject \x1b[3J for scrollback clearing). However, since it's only 1 day old with 0 stars, we're waiting for community validation before installing.

Would be great to see an official fix from Anthropic. The scrollback buffer issue with Ink seems to be the root cause.

---
Diagnostics performed by Claude Code Opus 4.5 (claude-opus-4-5-20251101) under claude-user@91.10....

## Confirming this issue - detailed diagnostics from our setup We're experiencing the same problem on our Hetzner CX32 server (4 vCPU, 8GB RAM, Ubuntu 24.04). Here are our findings after ~2 hours of systematic testing: ### Environment - Claude Code version: 2.1.4 - Platform: Linux (Hetzner CX32, Falkenstein DC) - Terminal: SSH via Termius (DSP mode: --dangerously-skip-permissions) - Two parallel sessions: root and claude-user ### Key Finding: Memory Growth Rate Comparison We ran two identical Claude Code sessions and measured memory growth: | Session | Runtime | RAM Usage | Growth Rate | |---------|---------|-----------|-------------| | claude-user | 23 min | 669 MB | ~29 MB/min | | root | 91 min | 350 MB | ~3.8 MB/min | The claude-user session had 7.6x faster memory growth! ### Timeline of claude-user session: `` Start → 467 MB +16 min → 571 MB (+104 MB) +24 min → 669 MB (+202 MB total) +30 min → 611 MB (after --continue restart, context loaded) ` ### Factors that seem to accelerate the issue: 1. **Larger CLAUDE.md** - 696 lines vs 146 lines (4.8x difference) 2. **More MCP servers** - 6 vs 2 3. **Plugins enabled** - 2 plugins (aichat, superpowers) vs 0 4. **Statusline command** - even after disabling claude-powerline, lag persisted ### Observations: - The --continue flag loads previous context, so it's NOT a clean restart (starts with ~500MB immediately) - Typing lag becomes noticeable around 500MB RAM usage - At 600MB+, typing is severely delayed (multiple seconds) - Root session with minimal config stays responsive much longer ### Workaround we're using: - Disabled statusline completely - Restart session (without --continue) when RAM exceeds ~500MB - Monitoring with ps aux | grep claude ### Note on claudescreenfix-hardwicksoftware: We reviewed the code posted above - it looks legitimate (clean JS, MIT license, hooks stdout.write to inject \x1b[3J` for scrollback clearing). However, since it's only 1 day old with 0 stars, we're waiting for community validation before installing. Would be great to see an official fix from Anthropic. The scrollback buffer issue with Ink seems to be the root cause. --- Diagnostics performed by Claude Code Opus 4.5 (claude-opus-4-5-20251101) under claude-user@91.10....

Community review is going to take a hot minute cuz I'm not a big developer lol...

But since you're running Claude on a VPs like I am..

I have a very interesting MCP tool in the works that will greatly benefit the community

It's called specmem!

Research available at https://justcalljon.pro/research-blog#specmem

You can rest assured my code for the Claude terminal fix is safe, you can go through it yourself, I've been making multiple updates/upgrades and switched to a PTY approach :)

Claude code uses nodejs

So just plant yourself between Claude and the node js lmao.

I myself don't know WHY Claude devs haven't implemented a fix, and why context from previous compactions even shows the fuck up in the first place!

They really need to work on that

@aranej would love to work with you guys!

this is unacceptable. Please fix this, it's critical not a small issue.
I CANT USE IT CURRENTLY

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.