90% of times after rebooting my Debian 13 system, Cursor doesnt work anymore: all terminals fail to open and the chat is not responding. What I do to workaround is just enter some prompt to make it timeout and be offered the “Reload Window” option, half of the time it recovers. This is very annoying.
Steps to Reproduce
Use Cursor.
Shutdown the computer.
Open the computer.
Open Cursor.
Hey, thanks for the report. This is a known class of bugs. On window startup, the extension host doesn’t initialize, so cursor-socket never activates. After that, the terminal, chat, and search break as a cascade. The broken state gets saved in workspace storage and replays on every launch, so Reload Window doesn’t always help. The screenshot with Agent Execution Timed Out is exactly this.
Most often this happens after an unclean shutdown like a crash, freeze, or sometimes a reboot, and we don’t have auto-recovery yet. A working workaround is to delete the workspace storage for the affected project.
Important: this will delete chat history and any workspace-specific state for that project. If you need anything from there, back up these folders first.
We’re already tracking this issue internally, but I can’t share an exact ETA for a fix yet.
To help us reproduce the Linux reboot trigger, after the next time it gets stuck, before you restart or reload, can you share the logs from that session? We need renderer.log, exthost.log, and ptyhost.log. You can open them via Command Palette Ctrl+Shift+P then Developer: Open Logs Folder. This will speed up debugging a lot.
Today it reproduced the issue and only renderer.log was created, no exthost.log or ptyhost.log today, only with yesterday’s timestamp. So note that the exthost.log is from yesterday when it was working. Also ptyhost.log from yesterday is 0 bytes
Thanks, I checked the logs. renderer.log confirms exactly the pattern I mentioned. The Connect transport never gets registered (No Connect transport provider registered), then agent-exec hits a registration timeout, and the git context also times out. After that, terminal, chat, and source control fail one after another.
The fact that fresh exthost.log and ptyhost.log were not created at all today, and yesterday’s ptyhost.log was 0 bytes, is actually a useful signal. The extension host isn’t starting correctly and it keeps replaying a broken state on every launch. I’ll add this to our internal tracking.
For now, the only reliable way to get out of this state is to delete the workspace storage for the project, like in my previous message:
Close Cursor first and back up the folders if you need chat history. After cleaning, open the project again with cursor /path/to/project.
If you want, after doing this cleanup, try using it for a couple of days with restarts and let me know if it stays stable or if the issue comes back. That helps us figure out if it slowly corrupts again or if it’s a one time bad state.
We’re tracking this issue, but I can’t share an exact ETA for a fix yet. If I get an update, I’ll reply in the thread.
