Listener Leak Causes Shell to Hang

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor accumulates unreleased event listeners (in getResources_AllAgentChanges and related paths) until the Extension Host becomes unresponsive. Hangs can occur immediately in some conditions (e.g. workspace with many files or active watchers), or only after extended Agent sessions with many file changes. Once affected, all Shell tool calls hang indefinitely, return pid: -1, or produce no output — making the Agent unusable without a full Cursor restart and session storage wipe.

Observed Behavior (two variants)

  • Immediate / early hang: Shell tool hangs or returns pid: -1 / empty output soon after starting an Agent session — e.g. first or early Shell tool calls. More likely with large workspaces, many open files, or active file watchers (builds, logs, hot reload).
  • Extended-session hang: After many file changes and tool calls over hours, listener count climbs (e.g. 200 → 354 → 479 → 1671 → 1760+). Console shows potential listener LEAK detected; shortly after, Shell tool stops working.

Conclusion: The same underlying listener leak can surface quickly or only after prolonged use; “extended session” is not required to trigger the hang.

Console Error (verbatim)

[002] potential listener LEAK detected, having 1760 listeners already. MOST frequent listener (557): 
check @ workbench.desktop.main.js:433
q @ workbench.desktop.main.js:436
d @ workbench.desktop.main.js:1197
...
getResources_AllAgentChanges @ workbench.desktop.main.js:...

The listener count climbs continuously during a session. Observed progression in other reports: 200 → 354 → 479 → 1671 → 1760+.

Root Cause (observed)

Every file change in the workspace fires _notifyAgentExecFileChange, which registers a new listener in getResources_AllAgentChanges without cleaning up the previous one. The leak can compound rapidly in long sessions (file watchers, build output, log files) or reach a critical level quickly in workspaces that already trigger many file-change events on load or first interaction.

Once the Extension Host is overloaded (whether from immediate churn or accumulated listeners), it becomes unresponsive. The Shell tool’s process spawner is directly affected — commands either:

  • Never spawn (pid: -1)
  • Spawn but output is never returned to the agent
  • Hang until manually skipped

Impact

  • Agent becomes fully blocked — cannot run any shell commands
  • No graceful recovery — starting a new chat session does NOT always fix it (leak is session-storage-level)
  • Only reliable fix: full Cursor exit + manual deletion of Session Storage + restart

Workaround steps:

  1. Close Cursor completely (File → Exit — not just close window)
  2. Delete: %APPDATA%\Cursor\Session Storage\ (all files)
  3. Delete: %APPDATA%\Cursor\workspaceStorage\ (all folder contents)
  4. Restart Cursor, open new chat session

Partial mitigation: .cursorignore excluding noisy directories (build output, logs, node_modules, etc.) can reduce file-change churn and may lessen both immediate and extended-session hangs — but does not prevent the leak.

Steps to Reproduce

Variant A — Immediate / early hang

  1. Open Cursor Agent on a workspace with many files and/or active file watchers (e.g. build output, logs, node_modules not fully ignored).
  2. Start a new chat and run a Shell tool command (e.g. simple echo or dir).
  3. Observe: command may hang indefinitely, return pid: -1, or return no output. Subsequent Shell calls also fail.

Variant B — After extended session

  1. Open Cursor Agent on a workspace with an active file watcher (many files changing during session).
  2. Run an extended Agent session — multiple tool calls, file edits, shell commands over several hours.
  3. Continue until the console shows:
    [002] potential listener LEAK detected, having 1760 listeners already.
    
  4. At this point, attempt to run any Shell tool command.

Expected (both variants): Shell tool executes and returns output normally.

Actual: Shell tool hangs indefinitely, returns pid: -1 with empty output, or returns no result. Agent is blocked and cannot proceed.

Operating System

Windows 10/11

Version Information

Version: 2.6
Beta Versions
Version: 2.7.0-pre.41.patch.0

Tried all, no fix!

Additional Information

Related / Duplicate Reports

Issue / Thread Description
Forum: “Run Command often freezes” (224+ replies) Shell commands hang after some cycles; Windows-heavy; ongoing since v1.2.4
Forum: “[761] potential listener LEAK detected, having 1671 listeners” Dec 2024, macOS + Windows, composer stops responding
Forum: “Listener leak detected causing agent to stop mid-track” Sep 2025 (v1.5.9), confirmed still present
GitHub Issue #3931 getResources_AllAgentChanges — 479+ listeners → Extension Host crash
GitHub Issue #3848 Shell tool returns empty output + pid: -1 on SSH remote
GitHub Issue #3612 Terminal commands hang in Agent mode

Does this stop you from using Cursor

Yes - Cursor is unusable

Hey, thanks for the super detailed bug report. Your stack trace analysis and root cause breakdown are really helpful.

This is a known issue. The listener buildup in the getResources_AllAgentChanges / registerDecorationType path has been reported by multiple users since mid-2025. The team knows about it and is tracking it.

One thing to note is that a related fix for a Monaco Editor lifecycle leak in ReviewChangesFileItem landed on March 8. It fixes diff editors not being cleaned up when they get recreated, which matches your stack trace. It might not fully solve the issue, but it could make it happen less often. If you’re on nightly builds, try updating to the latest and see if it helps.

Your .cursorignore workaround and the Session Storage wipe are solid. They’re probably the best options right now.

I’ve flagged this with the team. There’s no timeline yet, but your details, especially the listener count progression and the two repro paths, really help with prioritization. We’ll post an update here if there’s any news.

1 Like

This topic was automatically closed 22 days after the last reply. New replies are no longer allowed.