Very slow edit tool for agents in IDE

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

The agent edit tool is being super slow, taking approximately 10s for each simple edit in each file. Using WSL2 in Windows.

Steps to Reproduce

  1. Ask for agent to make changes in any file
  2. Agent uses Cursor’s edit tool and the changes start to appear in the edit tool window
  3. After agent finishes spilling all the tokens to edit, each tool call takes >10s for changes to actually happen and finish

Expected Behavior

Before, the edit tool was almost immediate after the agent finished outputting all the tokens necessary for the tool. Now after it finishes with the token’s output, it takes a long time for changes to take place. This completely breaks the workflow for the usage.

Screenshots / Screen Recordings

cursor-changes.png
cursor-changes.png908×242 7.08 KB

Operating System

Windows 10/11

Version Information

Version: 2.6.21 (system setup)
VSCode Version: 1.105.1
Commit: fea2f546c979a0a4ad1deab23552a43568807590
Date: 2026-03-21T22:09:10.098Z
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 AI issues: which model did you use?

Composer 2 and GPT 5.3 Codex High

Does this stop you from using Cursor

No - Cursor works, but with this issue

4

Hey, thanks for the report. We’ve seen similar WSL-specific slowness before. This looks related to a known issue with edit tool performance on WSL: Slow plan editing while using Auto

A couple of questions to help narrow it down:

  • Does your project live on the Linux filesystem, for example /home/..., or on the Windows filesystem, for example /mnt/c/...? Cross-filesystem access through WSL adds significant overhead.
  • Does the issue persist if you open the project directly in Windows, not through WSL?
  • Can you grab a Request ID from a slow edit? Chat context menu at top right > Copy Request ID

The team is aware of WSL-related performance issues. Your report helps with prioritization. The more data points we have, the better.

Let me know how it goes.

5

Hi Dean, thanks for the quick response. I’m happy to provide more details.

  • Filesystem location: the project is located on the Linux filesystem inside WSL (e.g. /home/...), not under /mnt/c.

  • Windows vs WSL: when opening the same project directly on Windows (outside WSL), the edit tool behaves normally and the slowness does not occur.

  • Request ID: I’ve captured a Request ID from a slow edit and will attach it here:
    Request ID:2189c4e6-7df1-4e0c-ba41-3be63fecc370

Let me know if you’d like me to run any additional diagnostics or collect more data points. Happy to help with prioritization.

Thanks again!

6

Thanks for the details.

Since it works fine when you open it in Windows but breaks in WSL, that points to WSL-specific overhead. Even though your project is on the Linux filesystem, which is the right setup, the edit tool still has to go through some IPC layers during the apply step, and that can add latency.

For now, one thing to try is to make sure you don’t have any heavy extensions running in the WSL session. You can check via Cmd+Shift+P > Developer: Open Process Explorer and see if extensionHost spikes during edits.

Let me know if anything changes on your end.