Extension host (role: retrieval) crash loop — exit code 6

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Extension host (role: retrieval) crash loop — exit code 6 within seconds of window open

Cursor: 3.11.13 (stable) · OS: macOS 26.5.1 (build 25F80), arm64 (Apple M5, 24 GB) · Electron: 40.10.3 · Node: 24.15.0

Summary

The extension host with role: retrieval crashes with exit code 6 (reason: 'crashed', no signal) within ~1 second of starting, three times in a row, on every launch of a specific workspace. The “Extension host terminated unexpectedly 3 times within the last 5 minutes” toast appears on every session. The chat/agent side panel hangs on “Loading Chat” indefinitely.

The crash reproduces with: a single window, Extension Bisect stopped, freshly recreated workspaceStorage (old one quarantined), no memory pressure (69% system-wide free), and no third-party extension involvement (crash persisted while bisect had extensions disabled).

Timeline / two distinct phases observed

Phase 1 — Filesync retry storm (resolved by workspace cleanup)

Initial crashes coincided with a cursor-always-local Filesync flood. The repo had accumulated ~80 git worktrees (agent-created: ~/.cursor/worktrees/workport-build/*, JetBrains Air agent worktrees, plus manual ones). Filesync attempted 510 file uploads in one burst across 18 worktree roots.

Server-issued FSConfig at the time:

rateLimiterRps: 10, rateLimiterBurstCapacity: 50,
rateLimiterBreakerResetTimeMs: 300000,
syncRetryMaxAttempts: 3, syncRetryInitialDelayMs: 20, syncRetryTimeMultiplier: 2

510 uploads against a 10 rps / 50-burst limit produced hundreds of RateLimitError: Rate limit exceeded exceptions (at wd.uploadFile → kd.executeForPath in cursor-always-local/dist/main.js) — dozens logged within the same millisecond, i.e. effectively no backoff at this layer. Each exthost crash → respawn → full re-sync → re-trip created a self-sustaining crash loop; the 5-minute breaker never got to reset.

Note: the account was at 100% of included plan usage when this began, in case server-side throttling behaves differently for exhausted accounts.

After pruning to ~30 worktrees, Filesync errors disappeared completely from subsequent sessions — but the exthost crash loop continued, leading to:

Phase 2 — Retrieval exthost dies after a burst of git ChildProcess failures (current state)

Clean-run exthost log (single window, bisect off), final second before crash:

19:33:21.710 [error] Activating extension github.vscode-github-actions failed due to an error:
19:33:21.710 [error] Error: Failed to execute git
    at ChildProcess.d (.../extensions/git/dist/main.js:21:12138)
19:33:22.059 [error] Error: Git error            <- repeated 7+ times at the same timestamp
    at ChildProcess.n (.../extensions/git/dist/main.js:33:2191)
    at ChildProcess.emit (node:events:521:24)
    at ChildProcess._handle.onexit (node:internal/child_process:295:12)
19:33:22.407  Extension host with pid 23353 exited with code: 6

Sentry event from the same run:

Error :: Extension host (LocalProcess [role: retrieval] pid: 23353) terminated unexpectedly. Code: 6, Signal: unknown

Additional renderer-side Sentry events at startup:

  • WorkingCopyLeakError: 513 working copies already. Most frequent owner (258)
  • ListenerLeakError escalating 200 → 600 listeners within ~1 s (Yll._createModelData)
  • resetComposers called - wiping all composers (existingComposerCount: 0)

Working hypothesis

41 worktrees were removed (git worktree remove / prune) while diagnosing Phase 1. Cursor state still references the deleted paths; on launch, git subprocesses fail in a simultaneous burst, and the retrieval exthost dies (unhandled ChildProcess error events → abort?). The crash survives a workspaceStorage reset, so the stale repo/worktree references appear to live in global (User-level) storage — which is where diagnosis stopped, since that also holds ~2,446 agent sessions the user cannot risk losing.

Eliminated during diagnosis

  • Third-party extensions (crash persisted under Extension Bisect with extensions disabled)
  • Workspace storage (crash persists with freshly recreated workspaceStorage/<id>)
  • Memory pressure (69% free at repro time; no oversized processes)
  • Filesync flood (Phase 1 resolved; no RateLimitErrors in current sessions)
  • Open-editor restoration (crash persists after Close All Editors)

Questions

  1. Where does the retrieval exthost / Git Graph cache its repository & worktree list, and how can stale entries be cleared without deleting agent chat history?
  2. Is the no-backoff RateLimitError retry burst in cursor-always-local Filesync a known issue for many-worktree workspaces?
  3. Is exit code 6 here an abort on unhandled ChildProcess error events, or OOM-internal? (No fatal error is written to exthost.log — it ends mid-activation.)

Full log bundles (3 sessions: 18:18, 19:15, 19:33 on 2026-07-12, Europe/London) available on request.

Steps to Reproduce

Detailed in the summary

Expected Behavior

lol, not crashing :slight_smile:

Operating System

MacOS

Version Information

Version: 3.11.13 (Universal)
VS Code Extension API: 1.125.0
Commit: 3f21b08f0b436a07be29fbfe00b304fa15553350
Date: 2026-07-10T01:45:28.254Z
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: Darwin arm64 25.5.0

For AI issues: which model did you use?

All

Does this stop you from using Cursor

Yes - Cursor is unusable

5

Hi Ben, thanks again for the detailed report, and I’m sorry you’re hitting this!

From the logs, this appears to be a Cursor extension host crash loop in that specific workspace, likely related to the large number of git worktrees / stale worktree paths. This does not look like an out-of-memory crash, and your chat history should not be at risk (chat history is stored separately from the workspace retrieval index / git state).

Could you try cleaning up stale worktrees for the affected repo?

  1. Run git worktree prune in the affected repository.
  2. Remove any leftover stale Cursor worktree entries under ~/.cursor/worktrees/ if they correspond to deleted worktrees.
  3. Reopen Cursor on that workspace.
7

Hey Colin, this is exactly what I did thank you!

What we found (in order):

1. Filesync retry storm. The workspace had accumulated ~80 git worktrees (mostly agent-created). cursor-always-local Filesync tried to upload 510 files across 18 worktree roots against a server config of 10 rps / burst 50, producing hundreds of “RateLimitError: Rate limit exceeded” (uploadFile → executeForPath) — dozens logged in the same millisecond, i.e. no effective backoff. Crash → respawn → full re-sync → re-trip = self-sustaining loop (the 5-min breaker never reset). Account was also at 100% of included usage at the time.

2. Pruned worktrees 80 → ~30 (git worktree prune + removing clean stale ones). Filesync errors disappeared completely — but the exthost kept crashing.

3. Corrupt git index. .git/index in the workspace was 0 bytes. Every git command failed instantly, and the exthost log shows a burst of 7+ identical “Error: Git error” (ChildProcess) at the same timestamp, followed ~300ms later by the exit-code-6 crash. Likely the index was corrupted by one of the earlier crashes.

Fix (both done, in this order, crash gone after):

- Quarantined the workspace’s state: moved ~/Library/Application Support/Cursor/User/workspaceStorage/ aside
- Rebuilt the corrupt index: rm .git/index && git reset

Can’t fully separate which of the two was decisive — but the mechanism in the logs (git ChildProcess failure burst → immediate exthost death) points at the index, with workspaceStorage likely holding stale references to the removed worktrees.

Two bugs for the Cursor team here, independent of my recovery:

1. Filesync retries rate-limited uploads with ~20ms delays and no real backoff, and re-slams on every exthost respawn — heavy background-agent users (many worktrees) will hit this.

2. The retrieval exthost hard-crashes (exit 6) on a burst of failed git child processes instead of surfacing “your git index is corrupt” — which would have turned a whole evening of debugging into a 30-second fix.

Log bundles from three sessions available — happy to share.