Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
Opening GitLens Commit Graph in a large git worktree makes Cursor go Not Responding. Activity Monitor shows Cursor Helper (Renderer) (sometimes labeled Plugin) at ~360% CPU. The same GitLens version, same repo, same Graph view is usable in VS Code.
This is not “GitLens is slow in general.” Isolation:
- Extension fully disabled → Stable
- Stripped GitLens (no Graph) → Stable
- CodeLens on → Stable
- Launchpad / PR polling on → Stable
- Open Commit Graph → Hang, Force Quit needed
Why this looks like a Cursor bug, not a GitLens bug:
GitLens Graph is a heavy webview (canvas/WebGL) that runs in the Chromium renderer. Cursor’s renderer already hosts the agent/chat UI, extra extension-host processes (user, always-local, retrieval, agent-exec), and Composer wakelocks that disable background throttling. VS Code 1.133 does not have that extra renderer load, and Cursor 3.16.17 is still based on VS Code 1.128.0.
Environment:
- Cursor: 3.16.17 (Stable), commit 6b2afae0257df2bb5e1835f15165dc2f0de056b0, VS Code base 1.128.0, Electron Framework 40.10.3
- VS Code (control): 1.133.0, commit a5b500951314efd502d07465bd138dfbd714a960
- OS: macOS 15.6 (Darwin 25.6.0), Apple Silicon (arm64)
- GitLens: 19.0.1 (same install in Cursor and VS Code)
- Git: 2.50.1 (Apple Git-155)
- Repo: large Nx frontend monorepo, ~40k commits, opened as a git worktree (frontend.worktrees/chore-nerd)
- git.openRepositoryInParentFolders: always
Repro:
- Open this large worktree in Cursor 3.16.17 with GitLens 19.0.1 enabled.
- Command Palette → GitLens: Show Commit Graph (or open the Graph view).
- UI freezes; macOS marks Cursor Not Responding; renderer CPU ~3.5 cores.
- Repeat in VS Code 1.133.0 with the same GitLens + same folder → Graph works.
Workaround:
Do not open Commit Graph in Cursor. Keep CodeLens/Launchpad. Settings that avoid auto-opening Graph:
“gitlens.graph.sidebar.enabled”: false
“gitlens.graph.sidebar.pinned”: false
“gitlens.graph.minimap.enabled”: false
“gitlens.graph.autoFetch.enabled”: false
Ask:
Please investigate GitLens Graph webview on Cursor’s renderer (webview lifecycle / service worker / background throttling vs VS Code 1.128→1.133). Happy to attach Process Explorer + DevTools console on request.
Steps to Reproduce
-
Open a large git worktree of a monorepo in Cursor 3.16.17 (example: ~40k commits, Nx frontend, folder like frontend.worktrees/chore-nerd). Do not use a tiny repo.
-
Confirm GitLens 19.0.1 is Enabled (same version that works in VS Code).
-
Open a few TypeScript files and click around. Editor should stay responsive at this point (CodeLens/Launchpad can be on).
-
Command Palette → GitLens: Show Commit Graph
(or GitLens side bar → Commit Graph / open the Graph view). -
Wait a few seconds after the Graph view appears.
Expected:
Graph renders. Cursor stays clickable, same as VS Code 1.133.0 with the same GitLens + same folder.
Actual:
Cursor goes Not Responding. Activity Monitor: Cursor Helper (Renderer) ~360% CPU (sometimes shown as Cursor Helper (Plugin)). Force Quit is required.
- Control: open the same folder in VS Code 1.133.0, same GitLens 19.0.1, run GitLens: Show Commit Graph. Graph works; no hang.
Operating System
MacOS
Version Information
Version: 3.16.17
VS Code Extension API: 1.128.0
Commit: 6b2afae0257df2bb5e1835f15165dc2f0de056b0
Date: 2026-08-14T01:41:12.803Z
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.291
OS: Darwin arm64 25.6.0
Does this stop you from using Cursor
Yes - Cursor is unusable
