As chats gets longer, the input component randomly disallows typing, effectively cutting the conversation off. The only way to fix this is to start a new chat.
Steps to Reproduce
Use auto for a while
Expected Behavior
The conversation should be allowed to continue.
Operating System
Windows 10/11
Current Cursor Version (Menu → About Cursor → Copy)
Hey, thanks for the report. This is a known issue and the team is aware.
A similar case came up in this thread, where a user debugged it and found that defaultPrevented is blocking keyboard events. It usually happens in long chats.
Try this workaround, it sometimes helps:
Press Ctrl+Shift+P in the chat window
Select “Developer: Reload Window”
If that doesn’t help, the only option for now is to start a new chat.
To help the team investigate, can you share:
About how many messages were in the chat when this happened?
Do you see any errors in the Developer Console (Help > Toggle Developer Tools > Console tab)?
Are you using multiple monitors, or opening the chat in a separate window?
I’ve added your report to help raise visibility on this issue.
I lost track of how many messages there were in the chat. It lasted over a day and when I scroll up, it just doesn’t have history beyond a certain point. I’m doing an architecture overhaul and I keep the chat going as long as possible because i don’t feel like rolling the dice with a new chat as to whether it will understand the context of what I’m doing or not.
There are actually quite a few errors. I don’t know what’s relevant and what isn’t.
I switch between multiple monitors and one screen. If I’m on one screen, I’ll open a diagram preview in another window or else it just isn’t readable.
I was able to recreate this bug closing Cursor when I have 2 windows open and then reopening it later. Reopening Cursor means the 2 windows come back and that is what causes the bug. Close one window, close Cursor, reopen, ctrl shift P, reload window fixes it.
Thanks for the extra info. It really helps that you found a specific trigger: closing Cursor with 2 windows open, then reopening it. That’s valuable info for the team.
Glad the workaround via Ctrl+Shift+P > Reload Window works for you. Closing one window before closing Cursor is also a good way to prevent the bug.
I’ve shared your findings about multiple windows with the team. It should help them reproduce and fix the issue faster.
I am avoiding the bug by just closing the second window before I close Cursor although it would be a nice-to-have to be able to close and reopen right back to my previous workflow with 2 windows.