[BUG] Interactive CLI degrades over time, leading to UI lag and repeated timeout errors
Open 💬 21 comments Opened Jan 12, 2026 by jorge-correia-software
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
After several prompts in a single interactive Claude Code CLI session, the CLI appears to accumulate excessive context and enters a degraded state. Typing becomes noticeably slow, requests stall, retries loop, and eventually every request fails with the error:
Request timed out. Check your internet connection and proxy settings
This occurs even though the network connection is stable and other Claude interfaces continue to work normally.
What Should Happen?
- Interactive sessions should remain responsive regardless of prompt count.
- Context growth should be handled gracefully or trimmed.
- Timeouts should reflect actual network failures, not internal degradation.
- Retry logic should not worsen the degraded state.
Error Messages/Logs
Request timed out. Check your internet connection and proxy settings
Retrying in 32 seconds...Steps to Reproduce
- Start an interactive Claude Code CLI session.
- Perform several sequential prompts involving code edits (e.g. refactors, theme changes, multi-file diffs).
- Allow the session to run for several minutes with accumulating context and streamed diffs.
- Observe increasing UI latency:
- typing in the terminal becomes slow
- cursor movement and redraw lag
- Eventually, requests stall and the CLI begins retrying.
- The CLI repeatedly outputs:
Request timed out. Check your internet connection and proxy settings
Retrying in 32 seconds...
- From this point onward, no requests complete successfully until the CLI is restarted.
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
2.1.5 (Claude Code)
Platform
Anthropic API
Operating System
Ubuntu/Debian Linux
Terminal/Shell
VS Code integrated terminal
Additional Information
_No response_
21 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
👍 - I'm getting the same
@jorge-correia-software I am also seeing the same problems in Claude Code v2.1.5, Ubuntu 24 server. I responded in another issue about similar issues. When the sluggishness occurs, check htop and see if one CPU core is pegged near 100%. This was my issue and only happens after some amount of token usage; new sessions do not have the issue until again some amount of token usage in the chat session. I downgraded to v2.0.76 and the issue does not re-occur.
I downgraded to 2.1.0 and it fixes it - haven't had a chance to work out
the exact version it breaks in yet.
On Mon, 12 Jan 2026 at 17:32, Parker H @.***> wrote:
I've seen this on 2.1.4 and 2.1.5 on Windows/WSL. 2.1.5 seems fine on macOS 26.2 but I wasn't paying attention to the context window size.
I've seen this starting today (1/12) on 2.1.5 (Claude Code)
Typing in the terminal is INSANELY slow and makes me want to claw my eyes out of my head with a dull knife.
I've resorted to typing in an editor and pasting in my side of the conversation, and the paste takes 0.5-2 seconds.
Completely restarting the terminal does not help; if you use "claude -c" to resume the conversation - whatever is going wrong - persists.
The bug appears to be due to an extreme amount of whitespace appearing in the terminal window and hence the conversation history. For some reason, this results in the terminal becoming slower and slower and also the api timing out. Once the api starts timing out, claude code pretty much can't do anything at this point.
To solve it, export your conversation to a txt file, open it in a text editor, remove all of the trailing whitespace, restart a fresh claude session and then import the cleaned up conversation. The conversation file will should be 50-70% smaller, and claude code will resume operating normally - until it fills up with whitespace again and you need to repeat the process.
This is on 2.1.5 btw.
I experienced the same issue on 2.1.5, upgrading to 2.1.6 didn't fix it. Downgraded to 2.0.76 but I noticed I couldn't resume any session that was running and 2.1.6 (or likely also 2.1.5) due to an error on resume (
Cannot read property 'trim' of undefined, or something similar to that). So I tried 2.1.1 - it seems to have fixed it and allows me to restore sessions, so I'll ride this for now. I seem to recall that 2.1.3 was also working fine but I haven't had time to fully test it yet.I have been noticing this as well, never had the issue before this week. The terminal just gradually slows down over time until each keystroke takes 500ms+ to render.
input lag through the roof
Experiencing this often lately. Happens on extended conversations.
JavaScript is not the language to build a long-running application in. I see this same type of issue eventually in any JS project of a certain size. Claude Code is also currently taking 2.68GB RAM in a TERMINAL APPLICATION, yet ANOTHER problem I often see in projects built in JS.
I switched to native install Claude Code v2.1.19 and this resolved it for me (mac OS).
I was getting the same thing. It definitely appeared to be a cli problem rather than anything related to the backend. It started ok, but then after a couple of prompts CPU would be pegged to 100% and it would be extremely laggy.
I have done the same as @matthewhegarty - I used
claude installto switch to the native install and updated to 2.1.23. It appears much better now.I confirm too that using native claude install resolved the problem in 2.17
same
On Thu, Jan 29, 2026 at 10:07 AM Adam Smith @.***>
wrote:
I have also switched to native install. The slowdown/whitespace-trimming problem is gone, now backspacing hangs or works intermittently. FWIW, I'm using MobaXterm on Windows 10, ssh'd into a 'remote' but local behind my NAT.
I've now switched to native install and am having the same issues still on long contexts :/
Experiencing same issue on macOS + Ghostty. Resumed session with 4.1GB conversation.json causes severe input lag (~500ms+ per keystroke).
Happens both with and without PTY wrapper. The issue persists even in a freshly opened tab in the same terminal session.
Additional observation: The claude process consumes 110% CPU while completely idle (no active request, just sitting at the prompt). This suggests continuous background processing of the large context.
Environment: macOS 15.3, Ghostty, Claude Code 2.1.27, Opus 4.5
Follow-up:
sampleoutput for the idle process consuming 110% CPU:Main thread is 100% busy (2499/2499 samples) while the CLI is completely idle at the prompt. No symbols available in stripped binary, but clearly an event loop or polling mechanism that doesn't yield when there's no work.
Full sample: process appears to be doing continuous work in the main thread even with no user input or API activity.
Request for debug assistance:
I have the problematic session readily reproducible (4.1GB context, 110% CPU while idle). Would be happy to help debug this further if Anthropic could:
sample/InstrumentsI can provide:
sampleoutput with symbolsThis seems like a significant issue affecting users with long-running sessions, and I'd like to help get to the root cause.
I've done extensive analysis on this exact problem. Using ccusage_go (open-source Claude Code usage tracker), I found that Cache Read tokens consumed 97.7% of my session costs — API actual cost was $1.47, total billed cost was $64.98 (a 44x markup). Cache also degrades instruction following in long sessions, which I documented with per-turn JSONL analysis.
Full write-up with data, community issue references, and Claude Code's own self-analysis report:
https://blog.sd.idv.tw/en/posts/2026-03-25_claude-code-cache-trap/
Tool: https://github.com/SDpower/ccusage_go