"No Connect transport provider registered" — AI chat broken in workspace windows on external volumes

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Workspace windows on external volumes consistently lose their Connect transport provider ~3 minutes after startup, making all AI chat features non-functional. The agent/empty windows continue to work fine. This happens on every restart unless all Cursor caches are cleared first.

Symptoms:

  1. Chat shows “Taking longer than expected…” then “An unexpected error occurred” with a Request ID
  2. Renderer log floods with No Connect transport provider registered errors every 10-30 seconds
  3. Errors include: Error fetching user pricing info, Error fetching user privacy mode
  4. Only affects workspace windows — agent (empty) windows work normally in the same session

Root cause from logs:
The Connect transport provider (gRPC-based, in workbench.desktop.main.js) fails to register for workspace windows that load from external/mounted volumes. The error originates at:

K9a.transport (workbench.desktop.main.js:43857:702901)
Zk.createSingleServer (workbench.desktop.main.js:43857:704493)

Contributing factors observed:

  • Workspace is on an external volume (/Volumes/Govinda/Firebird/)
  • File watcher refuses to watch the workspace: “Refusing to watch /Volumes/Govinda/Firebird/… for changes using fs.watch() for possibly being a network share where watching is unreliable and unstable”
  • globalStorage/state.vscdb grows to 1+ GB over time due to cursorDiskKV table accumulating massive bubbleId:* entries (50+ MB each for long chats), further degrading startup performance
  • Extension host goes unresponsive during startup when cweijan.vscode-database-client2 loads 644KB of global state

Workaround that temporarily fixes it:
Clearing all Cursor caches before launch:

rm -rf ~/Library/Application\ Support/Cursor/CachedData/*
rm -rf ~/Library/Application\ Support/Cursor/Cache/*
rm -rf ~/Library/Application\ Support/Cursor/GPUCache/*
sqlite3 ~/Library/Application\ Support/Cursor/User/globalStorage/state.vscdb \
  "DELETE FROM ItemTable WHERE key = 'cursorai/serverConfig';"
open -a Cursor

This works for one session. On the next normal launch (without cache clearing), the bug returns.

Secondary issue: server-side timeout on large chats
Chats with 1000+ messages / 15+ MB of bubble data cause server-side errors (Request ID returned) when attempting to send new messages. The server accepts the request but fails after ~20 seconds with “An unexpected error occurred.” Starting a new chat resolves this.

Steps to Reproduce

  1. Open a multi-root workspace from an external/mounted macOS volume (/Volumes/...)
  2. Have the cweijan.vscode-database-client2 extension installed with cached state
  3. Launch Cursor normally (without clearing caches)
  4. Wait ~3 minutes after startup
  5. Attempt to use AI chat in the workspace window
  6. Observe “Taking longer than expected” → “An unexpected error occurred”
  7. Check renderer.log: continuous No Connect transport provider registered errors

Expected Behavior

The Connect transport provider should register successfully for all windows regardless of workspace volume location. AI chat should function identically in workspace windows and agent windows.

Operating System

MacOS

Version Information

Version: 3.0.13
VSCode Version: 1.105.1
Commit: 607fad2793a66e8e63911e3159242a8a0d34eb8890c88cd17e860453065fd35b
Release Track: Stable

Does this stop you from using Cursor

Yes - Cursor is unusable

5

Hey, awesome bug report. The root cause write-up with logs is super helpful.

There are two related issues here, and both are known:

  1. state.vscdb bloat via cursorDiskKV

This is a known bug. The cursorDiskKV table keeps bubbleId:* records with no limit, and over time the DB can grow to multiple GB. Other users have hit this too:

The team is aware, but there’s no ETA yet for a retention policy. Your workaround of clearing caches and deleting cursorai/serverConfig is basically the best thing to do right now. For a more drastic fix, you can fully recreate state.vscdb:

# Fully quit Cursor
mv ~/Library/Application\ Support/Cursor/User/globalStorage/state.vscdb ~/Library/Application\ Support/Cursor/User/globalStorage/state.vscdb.bak
# On next launch, Cursor will create a fresh DB (~188 KB)

Side effect: you’ll lose some settings (trusted folders, etc.), but AI chat will still work.

  1. No Connect transport provider registered on external volumes

This is an interesting trigger we haven’t seen in this context before. The file watcher refuses to watch /Volumes/… (treats it like a network share), which slows extension host startup, and cursor-always-local doesn’t register the transport before the 2-minute timeout. Combined with a bloated state.vscdb, the timeout is basically guaranteed.

I passed this trigger to the team. Your detailed analysis helps with prioritization.

About the secondary issue with timeouts on very large chats (1000+ messages), that’s also tied to bubble data size in state.vscdb. For now, the best workaround is to start new chats periodically instead of letting a single chat reach thousands of messages.

Let me know if recreating state.vscdb stabilizes things, even if only for a while.