Agents freeze on grepping and subagents running. Composer and 5.5 used. Restarting IDE helps for a while but then the problem gets back. Sometimes it unfreezes by itself and sometimes it just last forever.
Reinstallation of IDE did not jelp
Steps to Reproduce
run planning or something in agent mode where largely grepping and subagents used. I usually run multiple agents concurrently
Not only with Grep, but also with Glob—I don’t understand the difference, but in short, it happens with any use of the built-in search tool. A partial workaround is to tell the agent not to use these tools and use Shell commands, but with enough context, the agent quickly forgets and gets stuck in an endless search again.
I haven’t noticed any issues with sub-agents on my end, but maybe I don’t use them very often.
Having the exact same issue since 2 hours ago. No difference when using different models; tried GPT 5.5 and Composer 2 but no change. Grep stuck forever.
Hey @stonianua,
This is a known performance issue affecting agent tool operations (Grep, Glob, and others) in recent versions. Our engineering team is actively working on fixes – the root cause has been identified and multiple patches are in progress.
A few things you can try while we ship the fixes:
Restart Cursor (full quit and relaunch, not just Reload Window) when the freeze occurs – this temporarily clears the issue
Reduce concurrent agents – running multiple agents simultaneously makes the freeze more likely
We’re working on getting the fixes into a stable release. I’ll update this thread once the patches ship.
To @Fabz , @Duugrim , @j-173 , @almkvist – thank you for confirming and sharing details. The rollback data point and the clarification about Glob and git diff being affected too is helpful.
Same issue. I’ve added a rule to avoid using built in grep and glob in favor of shell commands and limit concurrent subagents to 3. Continues to freeze the entire editor consistently when attempting pr review regardless of fresh start, restart, close and reopen, computer restart. There is no grace period where it works.
Using Windows 11 with WSL2
Start a new agent, enter fetch <link to pr> for review. Editor freezes and prompts to wait, restart, or close. Extraordinarily frustrating.
Version: 3.2.16 (user setup)
VSCode Version: 1.105.1
Commit: 3e548838cf824b70851dd3ef27d0c6aae371b3f0
Date: 2026-04-28T21:07:47.682Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200
Edition Windows 11 Pro
Version 25H2
Installed on 2/18/2025
OS build 26200.8246
Serial number <REDACTED>
Experience Windows Feature Experience Pack 1000.26100.297.0
WSL version: 2.4.11.0
Kernel version: 5.15.167.4-1
WSLg version: 1.0.65
MSRDC version: 1.2.5716
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.26200.8246
Distro: Ubuntu 24.04.1 LTS
WSL distro name: Ubuntu
Kernel: 5.15.167.4-microsoft-standard-WSL2
Architecture: x86_64
Host CPU: Intel Core Ultra 7 165U
CPU cores visible: 14
Memory: 31 GiB total, 21 GiB available
Swap: 8 GiB
Hypervisor: Microsoft
Virtualization: full, VT-x
PID 1: systemd
Screenshots below show 2 different instances when the editor froze. Both during pull request read.
@kyle-514 — the “wait, restart, or close” dialog means the extension host is becoming unresponsive. This is being actively worked on, with a particular focus on Windows and WSL environments.
@stonianua — good catch on Windows Defender. If you’re on Windows, adding Cursor’s installation folder and your workspace directories as exclusions in Windows Security is worth trying. Real-time scanning can interfere with the file operations agent tools rely on.
@kyle-514 — two things that would help us narrow this down further:
Does this also happen with a local project (not connected to WSL), or only when your workspace is in WSL?
Before triggering the freeze, try opening Developer Tools (Ctrl+Shift+I) and keeping the Console tab open. After the freeze and recovery, check for any red errors — a screenshot would help pinpoint the exact failure.
Fixes for the underlying extension host issue are in progress. Will update here when they ship.
Does this also happen with a local project (not connected to WSL), or only when your workspace is in WSL?
I don’t actually have github or local projects set up on Windows host. I’ll try to set it up to test.
Before triggering the freeze, try opening Developer Tools (Ctrl+Shift+I) and keeping the Console tab open. After the freeze and recovery, check for any red errors — a screenshot would help pinpoint the exact failure.
For whatever reason with the dev console open, I’m no longer prompted to reopen or restart. Not sure if it’s due to the dev console being open or recent update.
Only errors present in console when the UI freezes are the expected Trace spans collection is disabled… due to privacy settings. I have to force quite to restart and the developer console closes with it.
Interestingly, developer console logs for the successful agent replies show another error present. Likely unrelated.
workbench.desktop.main.js:29478 [TranscriptStore] Failed to append transcript, falling back to full write: Error: ENOENT: no such file or directory, open 'C:\home\<wsl_user_home>\.cursor\projects\[REDACTED]\agent-transcripts\ce4f12f8-138c-4313-a680-91a15e272040\ce4f12f8-138c-4313-a680-91a15e272040.jsonl'
at async open (node:internal/fs/promises:636:25)
at async writeFile (node:internal/fs/promises:1205:14)
at async $p.appendFile (file:///C:/Users/<windows-user>/AppData/Local/Programs/cursor/resources/app/out/main.js:137:16870)
writeFromStateIncremental @ workbench.desktop.main.js:29478
await in writeFromStateIncremental
(anonymous) @ workbench.desktop.main.js:41749
await in (anonymous)
flushWrite @ workbench.desktop.main.js:41749
flush @ workbench.desktop.main.js:41749
Jy0 @ workbench.desktop.main.js:41749
unregisterCheckpointHandler @ workbench.desktop.main.js:41749
runAgentLoop @ workbench.desktop.main.js:41749
It seems it’s mixing the path in wsl with the host drive when attempting to write the transcript. 'C:\home\<wsl_user_home>\.cursor\projects\[REDACTED]\agent-transcripts\ce4f12f8-138c-4313-a680-91a15e272040\ce4f12f8-138c-4313-a680-91a15e272040.jsonl' this is C: drive on windows host but rest of the path is wsl ubuntu. Not sure it’s related but seems a bug anyway.