[Bug] UI lag and freeze when accepting merge conflicts in editor

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When resolving Git merge conflicts for a file in Cursor, the editor hangs and fails to pick up or apply the selected change instantly. There is a noticeable delay/freeze before the resolution reflects, or the process gets completely stuck mid-resolution.

Steps to Reproduce

Open a project in Cursor with active Git merge conflicts.

Open a conflicting file with inline conflict markers (<<<<<<<, =======, >>>>>>>).

Click on a resolution action (e.g., Accept Current, Accept Incoming, or using AI inline conflict resolution).

Observed Behavior: The editor freezes or takes a significant amount of time to apply the changes to the file and update the staging/Git status.

Expected Behavior: The selected change should apply instantly and clear the conflict markers without UI lag.

Expected Behavior

The selected change should apply instantly and clear the conflict markers without UI lag.

Operating System

Linux

Version Information

Version: 3.12.29
VS Code Extension API: 1.128.0
Commit: cd1c87ff9b66021918fb9731605f8d1d5fd2f0b0
Date: 2026-07-21T03:26:05.811Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Linux x64 5.14.0-570.39.1.el9_6.x86_64

For AI issues: which model did you use?

i used opus 5 model

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hey there!

There are actually two different paths here that behave very differently, and it’d help to know which one you’re hitting:

  1. Accept Current / Accept Incoming / Accept Both (the plain buttons on the conflict) apply instantly - they’re just an in-editor text change, no model involved.
  2. Resolve with AI (the sparkle/AI option) sends the conflict to the model and waits for a response, so a few seconds before it applies is expected there, especially on a larger model.

To narrow down what you’re seeing, could you share:

  1. Which action you’re using when it lags - the plain Accept buttons, or Resolve with AI?
  2. Whether an agent/chat session is actively running in that window at the time, and roughly the repo size (number of tracked files) and the size of the file you’re resolving in.
  3. A quick Process Explorer capture during a freeze: Cmd/Ctrl+Shift+P → Developer: Open Process Explorer, then note which process spikes (CPU/memory) while it hangs.
  4. If it’s easy - does Developer: Restart Extension Host (from the Command Palette) make it snappy again right after?

One more thing worth trying: make sure you’re on the latest Stable (Help → About to check your version), since there have been editor/performance improvements since 3.12.

With the action + a Process Explorer snapshot, I can dig into exactly where the time is going. Let me know what you find!

Thanks for clarifying! I’m using the plain manual Accept buttons without any AI involvement.

It’s taking around 1–2 minutes to reflect changes on a .conf file (previously stuck for 5+ mins), with no active chat/agent sessions running. I’ll run the Process Explorer during the next lag and test restarting the Extension Host to give you a clear CPU/process trace.

Thanks, that capture helps a lot. Nothing’s actually CPU-bound (the conflict window is ~4%, everything else near 0%), so the wait is Cursor sitting on the filesystem after each accept, not heavy work - and it looks like you’ve got a multi-folder workspace open (“Untitled (Workspace)”), which makes that worse.

Quickest thing to try: open just the single repo folder on its own (File → Open Folder, a local-disk clone if you can) instead of the multi-folder workspace, then retry the accept. If it’s instant that way, that’s your workaround.

If it’s not, two quick questions: how many folders are open in that workspace, and do they (or your home directory) sit on a network/NFS mount rather than local disk?