My issue was resolved by adjusting my Windows PATH environment variable. Even though I had specified an absolute path to my shell in my configuration C:\foo\bar\zsh.exe, Cursor was often unable to run the shell. The problem manifested itself by Cursor failing to run any agent (even down in WSL, where the shell is entirely different). Once I added C:\foo\bar to my Windows PATH env variable, Cursor became happy again.
Though I’m happy that the problem is resolved, I’m surprised by 1) that this problem was intermittent and didn’t always fail and 2) that setting the PATH would affect running a shell defined with an absolute path.
1: If i start a new chat i loose all context
2: Can’t do that every 15 mins (average my chat get stuck)|
3: i dont use skills
4: i always use opus 4.6, never use the Auto mode.
Sometimes restarting cursor help unstuck, but most of the time a stuck session is dead and will never ever work again. Happens when context is charged by 20% or more.
Hey everyone, sorry for the delay on updating this thread.
The team is aware of the issue and it’s on their radar. There’s no timeline I can share yet, but every message here helps with prioritization. I collected new Request IDs from the thread and passed them along.
A few notes based on what users have reported since my last update:
Workarounds that helped some users (might not work for everyone):
Reindex the project: Cursor Settings > Indexing & Docs > Delete and Reindex
Disable HTTP/2: add "cursor.general.disableHttp2": true to settings.json, then restart Cursor
Check your cursor skills files: @Johannes_Claesson found the freeze was caused by incorrectly formatted .cursor/skills files where the frontmatter was missing the name: field. If you use skills, double-check the format.
Stop and continue: when it freezes, click Stop, then send continue in the same chat, or start a new chat with the same prompt.
For users in mainland China: chatwater shared that enabling TUN mode in the proxy client and routing *.cursor.sh through the proxy, not just cursor.com, fixes the issue.
If none of this helps, please share:
Request ID (top right menu in the chat > Copy Request ID)
Cursor version
OS
whether it happens in an empty folder with a simple prompt like hello
@f00z, a 10GB state.vscdb is definitely not normal and it can slow things down. Try this: close Cursor, find state.vscdb (usually in ~/.cursor/ or %APPDATA%/Cursor/), rename it or delete it, then restart. Cursor will recreate it. You’ll lose some local state like window positions, but it shouldn’t affect your projects.
@Naomi_Weiser, the fact it works locally on Ubuntu but not on Windows over a remote connection is a really helpful clue. That narrows it down to something in the remote or SSH chain. Are you using the Anysphere Remote SSH extension?
I’ll keep updating this thread as we make progress.
In the latest version, after running for a short while, it starts showing “taking longer than expected.” This happens regardless of whether I use Auto mode or other model modes. I’ve also verified that my network is not the issue. This is seriously affecting my user experience. Is there any official solution for this problem?
We’ve made some significant progress here on the road to Cursor 3.0. At the same time, “Taking Longer than Expected” tends to mask multiple underlying causes that are hard to work through / give updates on in a thread like this.
We’re going to close this thread and suggest creating new bug reports if you face the issue on Cursor 3.0 (or if you’re reading this in the future, whatever the latest version is!)
Making progress on errors like these (Taking longer than expected..., Waiting for Extension Host...) is a priority for us. Thanks for helping us work through these issues.
