“No Connect transport provider registered”エラーでCursorのAIチャットが外部ボリューム上のワークスペースで動作しない問題の原因と対処法

“No Connect transport provider registered”エラーでCursorのAIチャットが外部ボリューム上のワークスペースで動作しない問題の原因と対処法

冒頭文
外部マウントされたボリューム上に置かれたワークスペースをCursorで開くと、起動から数分後に「No Connect transport provider registered」エラーが繰り返し発生し、AIチャットが使えなくなる不具合が複数のユーザーから報告されています。本稿は発生状況、ログの読み方、暫定的な回避策、恒久的な対策候補を整理し、現場で再現・対処しやすい形でまとめます。問題はワークスペース固有で、同一セッション内のエージェント（空ウィンドウ）は影響を受けない点が特徴です。Cursor - Community Forum+1

問題の概要

外部ボリューム（例：macOSの /Volumes/... やネットワーク共有）にあるワークスペースをCursorで開いた場合、起動後およそ3分前後で接続層（Connect transport provider）が登録に失敗し、AIチャット関連の機能が「Taking longer than expected…」→「An unexpected error occurred（Request ID付き）」と変化して利用不能になります。レンダラーログ（Developer Tools）には10〜30秒間隔で「No Connect transport provider registered」が大量に出力され続けます。これにより「user pricing info」「user privacy mode」の取得失敗といった副次エラーも発生します。該当の報告は最近のフォーラムスレッドで複数確認できます。Cursor - Community Forum+1

再現手順（現場で確認しやすい手順）

ワークスペースが外部ボリュームにあることを前提に、Cursorを通常起動してワークスペースを開くと数分で現象が発生する、という再現性が報告されています。ログの観察ポイントはレンダラープロセスのエラー、拡張ホスト（extension host）の応答性低下、そしてUser/global state（state.vscdb）の肥大化状況です。フォーラムに寄せられた共有手順を踏めば再現が確認できます。Cursor - Community Forum

症状の詳細とログから読み取れること

レンダラーログにおける代表的なスタックトレースは、workbench.desktop.main.js 内で gRPC ベースと思われる Connect transport 層が登録できず例外を投げている箇所に集中しています。ログ中の行は sss.transport や createSingleServer を起点とするもので、これは内部の IPC/transport 初期化がワークスペース側で失敗していることを示唆します。また、state.vscdb（Cursor の globalStorage）や cursorDiskKV テーブルが巨大化して起動性能を悪化させ、結果としてタイミングに依存する初期化処理が失敗しやすくなる状態も観察されています。類似の報告は過去にも存在し、プロフィール破損や state.vscdb に起因するケースが確認されています。Cursor - Community Forum+1

主な寄与因子（フォーラム報告を基に整理）

外部ボリュームに起因するファイル監視（fs.watch）拒否、state.vscdb の急激な肥大（bubbleId:* の大量蓄積）、特定拡張（例：cweijan.vscode-database-client2 等）が起動時に大きなグローバルステートを読み込むことで拡張ホストが応答不能になる点が複合して問題を悪化させています。外部ボリュームを「ネットワーク共有として不安定」と判断し監視を拒否するログメッセージも報告されており、これがワークスペース固有の初期化ルートを阻害している可能性があります。Cursor - Community Forum+1

一時的な回避策（既報の手順）

現時点で確実に効果があると報告されている暫定的な手順は、Cursor のキャッシュとグローバルストレージを削除してから起動する方法です。ユーザー報告には、Caches/GPUCache などを丸ごと削除し、state.vscdb 内の cursorai/serverConfig キーを削除するとそのセッションではAIチャットが復活する旨が記載されています。ただしこの対処は一時的で、次回通常起動すると再発するケースが多数報告されています。該当の手順はフォーラムで共有されたコマンド例に基づいています。Cursor - Community Forum

恒久的な対策案（現場で試す順序と注意点）

以下はリスクと効果を踏まえた優先順候補です。実施前に必ずワークスペースと重要ファイルのバックアップを取ってください。

移動先をローカルディスクに変更する: 外部ボリュームではなくローカル（内部）ドライブのパスにワークスペースを移して起動を確認する。多くの報告でこれにより問題が回避できる例がある。Cursor - Community Forum
state.vscdb の肥大を解消する: globalStorage 内の大きなエントリ（特に cursorDiskKV の bubbleId:*）を整理・削除することで起動時間が改善し、IPC 初期化成功率が上がる可能性がある。直接編集する場合は sqlite3 等で慎重に行う。Cursor - Community Forum
拡張の一時無効化: 起動時に拡張が大量の状態を読み込むことで拡張ホストが固まる報告があるため、問題切り分けのために怪しい拡張を無効化して起動を試す。Cursor - Community Forum
アプリケーションプロファイルのリセットまたは新規 VS Code プロファイルを作る: 一部報告では新規プロファイルで問題が解消した事例がある。プロファイルが壊れている場合は有効な手段。Cursor - Community Forum
OS 権限やサンドボックス設定（Linux の AppArmor 等）の確認: Linux 環境では不完全な AppArmor プロファイルが原因でネットワークやシグナルの権限が不足し、同様の問題を引き起こすことがあるとの指摘がある。OS/ディストリでの対策は環境依存なので慎重に。Cursor - Community Forum

ログと対応をまとめた参照表

観測される症状・ログ	意味する可能性	優先対応
No Connect transport provider registered（レンダラーログ）	IPC/transport 層の初期化失敗	ワークスペースをローカルに移動して確認。state.vscdb の肥大確認。 Cursor - Community Forum
fs.watch 拒否メッセージ（外部/ネットワーク共有）	ファイル監視が働かずワークスペース初期化が不安定	外部→ローカルへ移動、または共有設定を見直す。
globalStorage/state.vscdb が巨大化	大きなセッション履歴が起動性能を悪化	不要なエントリ削除（バックアップ必須）。Cursor - Community Forum
拡張ホストが応答なし	拡張の読み込みで起動がブロック	問題の拡張を無効化して切り分け。Cursor - Community Forum

 

サーバー側タイムアウトと大チャットの影響

1000メッセージ／15MB以上といった大きなチャット履歴を持つ場合、送信リクエストがサーバー側で20秒程度で失敗する報告があり、結果的に「An unexpected error occurred（Request ID）」が返るケースが確認されています。サーバーはリクエスト自体は受け取るものの処理に失敗するため、大量履歴はチャットの新規メッセージ送信の信頼性を下げます。大履歴が多い場合は新しいチャットを作り直すことで解決するケースが多いとされています。Cursor - Community Forum

実務的なチェックリスト（導入現場向け短期施策）

上書きや削除の前に必ずバックアップを取り、影響を限定して検証すること。まずはワークスペースをローカルに移動して再現性を確認し、それで改善するなら外部ボリューム周りの監視設定やネットワーク共有設定を見直す。state.vscdb の肥大がある場合は、該当テーブルのサイズを計測し、安全な方法で不要エントリを削除する。問題が継続する場合は、ログ（レンダラ、shared process、extension host、state.vscdb のスナップショット）を添えて Cursor サポート／フォーラムへ報告する。Cursor - Community Forum+1

まとめと推奨アクション

現時点での最も実用的な対応は、影響を受けるワークスペースをまずローカルディスクに移して検証することです。並行して state.vscdb の肥大化をチェックし、不要なエントリ削除や拡張の無効化で起動負荷を下げることで、Connect transport の初期化が成功しやすくなります。根本的修正はアプリ側（Cursor）が外部ボリュームや大規模 state に対する初期化ロジックや監視方法を修正することに依存するため、現象を再現できるログを用意して公式フォーラム/サポートへ報告することも重要です。現行のフォーラムスレッドや既往の報告を参照しつつ、上記の順で切り分けを進めてください。Cursor - Community Forum+2Cursor - Community Forum+2