[BUG] Command line tool becomes slower and slower as session progresses, slowness seen in keyboard response when typing and pressing enter on the prompt submission
Status Open
Reported on v2.1.25
Maintainer reply None cached
Activity 3 comments · opened Jan 31, 2026
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?
Latest version, I think 2.1.25+, now 2.1.27, as session goes, the time between I press the key when typing the prompt and the char appearing on the CLI takes longer and longer. What is more noticeable is that when you press enter, it takes longer and longer to send the prompt, even slower than typing response by like 100x.
What Should Happen?
When you type, chars should show up immediately.
When you press enter, the prompt should show as submitted immediately.
Error Messages/Logs
Steps to Reproduce
Run a session in MacOS latest and see for yourself, it is always now happening.
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
2.1.17
Claude Code Version
2.1.27
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
_No response_
3 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
I can confirm that, claude code got unusable slow recently, on all my devices. Probably going to cancel the subscription soon, because I can't use it in opencode anymore.
I was going to create a separate issue for this, but adding a comment here will be just as good. From what I understand, Claude Code uses Ink to render everything about our interaction pane as we are typing and reading, etc. For every keystroke that we make, we are re-rendering the entire conversation. That means that the longer the conversation goes on, the laggier it gets to type. I was asking Claude Code about the issue, and it recommended that if any text that were completed were rendered as static scrollback, and only use Ink for the active input/response area, it might lower the amount of content that has to be dynamically rendered on every keystroke. I think we could all agree that in the early stages of a session, the lag involved with typing is completely tolerable, and hardly noticeable, but it is only after the conversation has gone on for a while that we start ctrl+g'ing to type into notepad. This would just create a predictably fixed area that is getting that dynamically rendered treatment, to maybe reduce the lag involved with typing.
Another alternative would be to shift, or provide an option, to have the CLI function more like traditional CLI's and forego a lot of the cool animations and stuff in favor of providing users with a lagless input experience, when CLI's just ask for responses, or keyed input. Rather than everything being within the enclosure of Claude Code, it would be that Claude Code is asking for a response, which happens more at the terminal level, and reported back to Claude Code. The tradeoff would be losing some of the cool interface things, but if it solves this problem down to zero, then maybe that would be worth it.