Still present in 3.20.0 on Windows 11. I checked the 3.20.0 bundles against what we traced on 3.19.14 and 3.19.16. The three code paths below are unchanged, so this build did not fix the Agents window problem. All evidence is inline.
Environment
OS: Windows 11 (10.0.26200)
Cursor: 3.20.0 stable, commit 4c0fe9acf024d051c47ffe28c48918ef6835f370, built 2026-09-07T23:10:23Z, Agents / Glass layout
VS Code Extension API: 1.128.0
Machine: Threadripper 3990X (64 cores), 256 GB RAM. Usually 20 or more agent chats open in the Agents window.
- Renderer memory: every persisted inline diff is restored eagerly at window start
Kevin wrote on thread 170166 on Sep 1: “Pending changes are restored into the reloaded window, which contributes to it coming back at 1.6 GB.” That restore is the memory floor on this machine.
Sep 6 (3.19.14), Agents window, DevTools heap snapshot with no chat open: 517 TextFileEditorModel instances, all file: URIs, for files no editor in that window had open. Every one was held through the modelRef of an inline diff handler, 522 handlers in the diffHandlers map of the InlineDiffService singleton. Renderer heap was 471 MB with no chat open. renderer.log one second after the workspace loaded: Potential working copy LEAK detected, having 513 working copies.
Where it comes from: InlineDiffService.loadInlineDiffs() reads every persisted diff for the workspace out of state.vscdb (cursorDiskKV rows inlineDiff:<workspaceId>:<diffId>, the review state of every agent edit nobody clicked Keep or Undo on; 1,258 rows for one workspace on Sep 6, and nothing prunes them). It then checks the client feature gate park_inline_diffs. In 3.20.0 that gate is still park_inline_diffs:{client:!0,default:!1}, so the default path is restoreAllStoredDiffsEagerly: a live model reference, text model and listeners for every distinct file, kept for the life of the window. Diffs with visible decorations also set the file back to its original text, re-apply the edit and force a save (77 files rewritten on disk at every window start here).
The gate ON path already does the right thing: pruneStoredDiffs keeps the 128 newest, restores only diffs whose file already has an open model, parks the rest as metadata and restores one when its file is opened. I forced that gate on locally on Sep 6. The Potential working copy LEAK line has not appeared since, zero in the 3.19.16 and 3.20.0 session logs. Please default park_inline_diffs to true, or turn it on for everyone.
- Renderer listener leak on $onAgentExecFileChange, still firing in 3.20.0
Two events in this 3.20.0 session so far, at 2026-09-08 01:26:32 and 2026-09-08 02:11:37, same stack both times. renderer.log, trimmed to the relevant frames:
2026-09-08 01:26:32.097 [error] potential listener LEAK detected, popular: Error
at V6v.create (workbench.glass.main.js:53:14063)
at hTs._event [as onDidChange] (workbench.glass.main.js:55:2733)
at new JO (workbench.glass.main.js:228:34972)
at aKl._createModelData (workbench.glass.main.js:20761:2522)
at aKl.createModel (workbench.glass.main.js:20762:1283)
at m9e.doCreateTextEditorModel (workbench.glass.main.js:11928:36329)
at m9e.resolveFromFile (workbench.glass.main.js:20740:17736)
at async nKl.createModelReference (workbench.glass.main.js:20740:32518)
at async jXl.maybeHoldGlassLspTextModelReference (workbench.glass.main.js:20970:2187)
at async jXl._handleFileChangeImpl (workbench.glass.main.js:20970:5571)
at async C.provider.createRemoteAccessor.composerId [as fileChangeHandler] (workbench.glass.main.js:20971:34853)
at async aEs.$onAgentExecFileChange (workbench.glass.main.js:20566:571808)
Each agent file change event resolves a text model in the Agents window renderer through maybeHoldGlassLspTextModelReference. The models are retained, and the shared onDidChange emitter they subscribe to accumulates listeners until the detector fires. Same entry point as the Aug 26 post in this thread on 3.17.21. The park_inline_diffs gate does not touch this path. This is the one I have no workaround for.
- Extension host: the agent store sync lists every mounted store every 5 seconds and launches whoami.exe four times a second per chat
One cloud agent store is mounted per live chat, plus the user’s own store. In cursor-agent-exec/dist/main.js (the bundled agent store sync engine) the periodic full sync round is scheduled syncDebounceMs after the previous round ends, whether or not anything changed. In 3.20.0 the defaults object still reads syncDebounceMs:5e3 and the clamp is still syncDebounceMs:{min:250,max:36e5}. On top of that, forceSync() runs an on-demand full round for every caller that wants the store fresh, so each chat event lists every mounted store in lockstep. Measured on 3.19.14 (Sep 6, one hour, 12 mounts): 8,072 aiserver.v1.BackgroundComposerService.ListAgentStoreDirectory calls, 2.24 per second sustained, bursts of 12 per second, while every store’s files/ directory was empty. The calls are logged in the window’s exthost/anysphere.cursor-always-local/Cursor Structured Logs.*.log as "metadata":{"method":"ListAgentStoreDirectory"}.
The lock check is the expensive part. The same engine runs setInterval(()=>{this.checkExclusiveMutationClaim()},Nn) with Nn=250 per mounted store, and the identity lookup inside it is execFileSync("whoami",["/user","/fo","csv","/nh"]), a synchronous process launch on the extension host’s only thread, recomputed on every tick. That is about 4 whoami.exe launches per second per live chat. A CPU profile of the extension host on 3.19.16 (Sep 7) spent 97% of a 20 second sample inside spawnSync on that call. On Sep 6 with only 4 chats open, tool calls in the Agents window ran at an 8.8 s median (Read 2.0 s, Write 9.2 s, shell 10.7 s) on an otherwise idle 64 core machine, because every tool call queues behind those spawns. Both literals are unchanged in 3.20.0.
Local experiment on Sep 6 and 7: periodic round at 60 seconds instead of 5, on-demand full rounds skipped, and the whoami result cached for the life of the extension host. The Agents window tool call median went from 8.8 s to 10 to 50 ms and has stayed there through the 3.20.0 update (2,625 tool calls across 22 chats in the last hour). So those two paths are the tool latency, and nothing on this machine writes to those stores from elsewhere, so a 5 second listing timer does no work here.
Asks: default park_inline_diffs to true, cache the whoami SID once per extension host, and let the periodic store round back off when the previous round found nothing. Item 2 is the remaining leak on your side.