Agents freeze at grepping and subagents

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

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

680b3d72-4cc7-4333-80a2-6aa68208b990
e2dc611d-faa2-401b-bcae-72b09986e407
584af618-0cb5-4c68-a4cd-d1cfa1f74094
8fdf75f9-4d5a-49b8-9f53-1925a34ca009

Expected Behavior

it should work smooth?

Screenshots / Screen Recordings

Operating System

Windows 10/11

Version Information

Version: 3.2.11 (user setup)
VSCode Version: 1.105.1
Commit: e9ee1339915a927dfb2df4a836dd9c8337e17cc0
Date: 2026-04-24T14:36:47.933Z
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

Does this stop you from using Cursor

Yes - Cursor is unusable

Same for me on windows 11

Version: 3.2.11 (user setup)
VSCode Version: 1.105.1
Commit: e9ee1339915a927dfb2df4a836dd9c8337e17cc0
Date: 2026-04-24T14:36:47.933Z
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

Back to 3.1.17 work

Same problem.

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.

I’m having the same issue with grep and git diff.

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:

  1. Restart Cursor (full quit and relaunch, not just Reload Window) when the freeze occurs – this temporarily clears the issue

  2. 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.

I found out Windows Defender blocked Cursor installation folder out of the blue. Perhaps it could be a reason for grep freezes.

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.

Same issue here. Stuck on grep.

Windows 10, Cursor 3.2

Rolled back to Cursor 3.1 seems to be working now.

So if you need a workaround for now, try downgrading your Cursor version:

it works thank you!

@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:

  1. Does this also happen with a local project (not connected to WSL), or only when your workspace is in WSL?

  2. 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.

Curosr has been updated .

Version: 3.2.21 (user setup)
VSCode Version: 1.105.1
Commit: 806df57ed3b6f1ee0175140d38039a38574ec720
Date: 2026-05-03T01:46:14.413Z
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

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.