Incident Report: Cursor Extension Host Crashes & Source Control Disconnections¶

Date: 2026-03-17 Severity: LOW (stability issue, no security impact) Affected system: Local development machine (macOS) IDE: Cursor Status: Resolved (updated after recurrence)

Executive Summary¶

The Cursor Source Control pane was intermittently losing connection to the git repository -- going blank for several seconds before re-scanning and returning to normal. Investigation revealed the Cursor Extension Host process was crashing and auto-restarting, taking the built-in git extension down with it. The crashes were caused by a combination of memory pressure from too many extensions, an orphaned MCP server registration, and a failing Nx Console MCP server flooding the logs with reconnection errors.

A security audit of the local machine was also performed (prompted by a concurrent crypto miner incident on the CI build agent). No indicators of compromise were found.

Symptoms¶

• Source Control pane in Cursor would go blank ("no repository") for 3-5 seconds
• After a brief pause, Cursor would re-scan the workspace and Source Control would return
• This happened repeatedly throughout development sessions
• The IDE status bar showed "The extension host terminated unexpectedly. Restarting..."

Root Cause Analysis¶

Extension Host Crash¶

The Cursor renderer log captured the crash at 09:47:40 UTC:

Extension host (LocalProcess [role: user] pid: 10042) terminated unexpectedly.
Automatically restarting the extension host.

The crash killed all 31 running extensions simultaneously, including vscode.git and vscode.git-base, which caused the Source Control pane to lose its repository connection until the Extension Host restarted and the git extension re-activated (~424ms to activate, plus repository scan time).

Contributing Factors¶

1. Nx Console MCP Server (port 9639)

The Nx Console extension starts an MCP HTTP server on port 9639. When the Extension Host crashed, this server died. On restart, Cursor's MCP infrastructure attempted to reconnect before Nx Console had re-initialized, creating a cascade of errors:

Client error for command fetch failed
Error connecting to streamableHttp server, falling back to SSE: fetch failed
Client error for command SSE error: TypeError: fetch failed:
  connect ECONNREFUSED 127.0.0.1:9639, connect ECONNREFUSED ::1:9639

Each reconnection attempt generated multiple log entries, contributing to memory pressure and destabilizing the Extension Host further. The Nx Console MCP was already in "minimal mode" with most tools disabled (replaced by Nx skills), making the server largely redundant.

2. Orphaned GitKraken MCP Server Registration

GitLens had been uninstalled, but its MCP server ID (user-eamodio.gitlens-extension-GitKraken) remained in Cursor's global state database. This caused unnecessary connection attempts to a server that no longer existed.

3. Heavy Extension Load

31 extensions were running at crash time, including several resource-intensive ones that were not actively needed:

4. Large Object Serialization Failures

The renderer log showed multiple "Unable to log remote console arguments Output omitted for a large object that exceeds the limits" errors immediately before the crash, indicating memory pressure from large data structures (likely AI conversation state).

Crash Timeline¶

Detailed log timeline:

Security Audit Results¶

A security audit was performed on the local machine due to a concurrent crypto miner incident on the CI build agent. No indicators of compromise were found.

The local machine was not affected by the build agent compromise. The CI attack vector (publicly exposed PostgreSQL) did not apply to the local environment.

Remediation Actions¶

Applied (2026-03-17)¶

Configuration Change¶

Added to ~/Library/Application Support/Cursor/User/settings.json:

"nxConsole.mcpToolsFilter": ["!*"]

This disables all Nx Console MCP tools while keeping the extension itself functional for its UI features (project tree, generator UI, etc.). The Nx workspace skills defined in AGENTS.md provide the same capabilities that the MCP tools offered.

Impact (Initial Incident)¶

Recurrence: Sustained Extension Host Crash Loop (2026-03-17, later session)¶

Symptoms¶

The extension host began crashing repeatedly with exit code 5 (native process crash), triggering a crash-restart loop. Unlike the initial incident (single crashes with recovery), this was a sustained loop — 7+ crashes in ~30 minutes — making the IDE largely unusable.

The Cursor main log showed a repeating pattern:

Extension host with pid XXXXX exited with code: 5, signal: unknown.
[UtilityProcess id: N, type: extensionHost, pid: XXXXX]: crashed with code 5 and reason 'crashed'

Crash Timeline (Recurrence)¶

The pattern was clear: the extension host would restart, consume memory while re-indexing, and crash again within 1-2 minutes.

Root Cause Analysis (Recurrence)¶

The crash loop was caused by a combination of factors that amplified each other:

1. SpecStory history partially excluded from .cursorignore

The .cursorignore file only excluded .specstory/ai_rules_backups/, leaving .specstory/history/ (813 markdown files, 477 MB) fully visible to Cursor's retrieval/indexing system. The retrieval extension host (anysphere.cursor-retrieval / anysphere.cursor-always-local) was attempting to index all of this content.

2. Retrieval extension host resource consumption

The retrieval extension host process was consuming 660 MB RAM and 432% CPU (pegging 4+ cores) while indexing the SpecStory files. This left the system with virtually no free memory.

Total Cursor memory consumption: ~2.6 GB.

3. System memory exhaustion

The machine (16 GB RAM) was down to 56 MB free pages (Pages free: 3573 at 16 KB/page). macOS was likely terminating the extension host process via memory pressure signals, manifesting as exit code 5.

4. Workspace storage bloat

• The workspace storage images/ cache had accumulated 845 files totaling 391 MB
• The state.vscdb database was bloated — the storage layer reported a DB size of ~6.6 GB (DB size: 7089504256b) with a slow close warning (detected slow close() operation: Time: 7207ms)
• The largest key was aiCodeTrackingLines at 1.5 MB

5. Window reload insufficient

A Developer: Reload Window did not resolve the issue because: - The retrieval extension's in-memory index persisted across reloads - The bloated workspace storage was re-loaded on each restart - The .cursorignore update was not fully picked up without a cold start

Remediation Actions (Recurrence)¶

Workspace Storage VACUUM¶

The state.vscdb SQLite database can become bloated over time, especially after crash loops where the WAL (write-ahead log) grows without proper checkpointing. To compact it, run the following command while Cursor is fully closed (Cmd+Q, not just reload):

sqlite3 ~/Library/Application\ Support/Cursor/User/workspaceStorage/aa64293d59ced24e9c943cf995ed4f74/state.vscdb "VACUUM;"

Note: The workspace storage ID (aa64293d...) is specific to this workspace. To find the ID for a different workspace, check workspace.json inside each folder under ~/Library/Application Support/Cursor/User/workspaceStorage/.

This does not need to be run on a regular basis. Under normal operation, SQLite handles compaction automatically. Only run it as a diagnostic step if extension host crashes recur or Cursor logs report slow close operations (detected slow close() operation).

.cursorignore Change¶

- # SpecStory backup files
- .specstory/ai_rules_backups/
- ai_rules_backups/
+ # SpecStory (history files are ~500MB and cause indexer crashes)
+ .specstory/

Result After Remediation¶

The extension host stabilized after applying all four remediation steps and has not crashed since.

Lessons Learned¶

1. .cursorignore must cover entire generated directories, not just subdirectories. Partially ignoring a large directory (only ai_rules_backups/ within .specstory/) left hundreds of megabytes of files exposed to the indexer.

2. Window reload is not a cold restart. In-memory indexes and cached state survive a reload. A full quit (Cmd+Q) is necessary when the extension host is in a crash loop.

3. Workspace storage accumulates silently. The images cache (845 files, 391 MB) and bloated SQLite database grew over weeks without any visible warning until they contributed to crashes.

4. Monitor the retrieval extension host. On a 16 GB machine, the retrieval extension consuming 660 MB + 432% CPU is a clear warning sign. Checking ps aux | grep cursor can quickly identify runaway processes.

Overall Impact¶