Cursorの「waiting for extension host」で詰んだ時に読む復旧手順まとめ
CursorでAIチャットやAgentを使おうとしたときに「waiting for extension host」と表示されたまま進まない場合、単なる通信待ちではなく、拡張機能を動かす内部プロセスが止まっている、または応答できない状態になっている可能性があります。実際に調査すると、Cursorの更新直後、拡張機能の競合、ユーザープロファイルの破損、キャッシュの不整合、大きすぎるワークスペース、ネットワーク設定など、複数の原因が重なって発生しているケースが目立ちました。
この記事では、「cursor waiting for extension host」と検索している人に向けて、まず何を確認すべきか、どの順番で直すと無駄が少ないか、Windows・Mac・Linuxでどのフォルダを見ればよいか、ダウングレードや初期化はどの段階で検討すべきかを整理します。体験談ではなく、公開されている不具合報告やエラー解説をもとに、今すぐ試せる順番でまとめています。
| この記事のポイント |
|---|
| ✅「waiting for extension host」の正体がわかる |
| ✅ CursorのAI機能が止まる理由を切り分けられる |
| ✅ 拡張機能・キャッシュ・設定・バージョンの順で復旧できる |
| ✅ 再発を減らすためのチェック項目がわかる |
cursor waiting for extension hostが出る主な原因と最初に試す復旧手順
- How to fix cursor waiting for extension host?の答えは拡張機能と設定を順番に切り分けること
- waiting for extension hostはAI機能の故障ではなく拡張機能ホストの応答停止で起きることが多い
- Cursor更新直後に出た場合はバージョン不具合の可能性を先に疑うべき
- 拡張機能をすべて無効化して起動できるか確認するのが最短の切り分けである
- PrettierやJupyterなど重い拡張機能は優先的に確認すべき候補である
- キャッシュとユーザー設定の破損は再インストールだけでは残ることがある
- Why does the cursor take so long to generate?はRulesやSkillsの読み込み待ちも関係する場合がある
How to fix cursor waiting for extension host?の答えは拡張機能と設定を順番に切り分けること
「cursor waiting for extension host」を直したい場合、最初にやるべきことは、いきなり再インストールすることではありません。調査した範囲では、効果が出やすい順番は 拡張機能の無効化 → Cursorの再起動 → ログ確認 → キャッシュや設定のリセット → バージョン変更 です。
このエラーは、CursorのAIそのものが必ず壊れているというより、AI AgentやComposerが内部で利用する「Extension Host」にアクセスできないときに出ることが多いです。Extension Hostとは、VS Code系エディタで拡張機能を動かすための裏側のプロセスです。ここが止まると、拡張機能だけでなくAI機能まで巻き込まれて止まることがあります。
特にCursorのフォーラムでは、更新直後に「Agent execution provider did not respond within 16 seconds」というエラーが出て、Agent、Ask、各モデルが使えなくなったという報告がありました。つまり、モデルをGPT系に変える、Claude系に変える、Gemini系に変えるだけでは解決しないケースがあります。
まずは次の流れで確認すると、原因の当たりをつけやすくなります。
📌 復旧の優先順位テーブル
| 優先度 | やること | 狙い |
|---|---|---|
| 1 | Cursorを完全終了して再起動 | 一時的な停止を解消する |
| 2 | 拡張機能をすべて無効化 | 拡張機能の競合を切り分ける |
| 3 | ログを確認 | クラッシュ原因の手がかりを見る |
| 4 | キャッシュや設定をリネーム | 破損した状態を避ける |
| 5 | Cursorのバージョン変更 | 更新由来の不具合を回避する |
ここで重要なのは、一度に全部やらないことです。全部まとめて削除・再インストールしてしまうと、何が原因だったのか分からなくなります。再発したときにも同じ作業を繰り返すことになりやすいため、ひとつずつ確認する方が結果的に早いです。
また、フォーラム上では「Reload Window」「Restart Extension Host」「再起動」だけでは改善しない例も複数見られました。反対に、特定バージョンへ戻したり、state.vscdb のリネーム、設定フォルダの削除で改善したという報告もあります。これらは環境差が大きいため、この記事では「軽い対処から順番に進める」形で整理します。
🔍 まず確認したい症状リスト
| 症状 | 見るべきポイント |
|---|---|
| AIチャットだけ止まる | Extension HostがAI関連処理に応答できていない可能性 |
| 全拡張機能が動かない | Extension Host自体のクラッシュを疑う |
| 更新直後から発生 | Cursor本体のバージョン不具合の可能性 |
| 特定プロジェクトだけ発生 | ワークスペースの重さやファイル数を疑う |
| どのプロジェクトでも発生 | ユーザー設定・キャッシュ・本体更新を疑う |
参考: Cursor Community Forumでは、Cursor 2.4.14付近で「Agent Execution Timed Out」とともにExtension Host応答待ちになる報告が出ています。
https://forum.cursor.com/t/after-last-update-stuck-at-waiting-for-extension-host/149538
waiting for extension hostはAI機能の故障ではなく拡張機能ホストの応答停止で起きることが多い
「waiting for extension host」と表示されると、CursorのAIサーバーや契約プランの問題だと考えたくなります。しかし、調査した情報を見る限り、まず疑うべきは Cursor内部の拡張機能ホストが動いているかどうか です。
Extension Hostは、簡単に言えば「拡張機能をまとめて動かしている裏方」です。CursorはVS Codeをベースにしたエディタなので、VS Codeと同じように、テーマ、フォーマッター、Python、Jupyter、Git、AI補助などの拡張機能をExtension Host上で処理します。ここが落ちると、表面上は「AIが返事をしない」「Agentが起動しない」「チャットが送れない」という見え方になります。
RapidDevの記事では、「Extension host terminated unexpectedly」は、拡張機能を実行するプロセスがクラッシュした状態だと説明されています。さらに、CursorのAI機能もExtension Hostに依存しているため、ホストが落ちるとTab補完、インラインチャット、Composer、Agentが止まるとされています。
この点を理解しておくと、対処の順番を間違えにくくなります。モデル変更、プロンプト変更、ネット回線の再接続よりも、まずは拡張機能と設定の状態を見るべきケースが多いからです。
🧩 Extension Hostと影響範囲の整理
| 内部要素 | 役割 | 止まったときの影響 |
|---|---|---|
| Extension Host | 拡張機能を動かすプロセス | 拡張機能・AI機能が不安定になる |
| Composer / Agent | AI作業の実行画面 | 応答待ちやタイムアウトになる |
| 拡張機能 | Prettier、Python、Jupyterなど | 競合・破損でHostを巻き込む場合がある |
| ユーザー設定 | Cursorの設定・ログイン状態 | 破損すると再起動では直らない場合がある |
| キャッシュ | 拡張機能や内部データの一時保存 | 古い状態が残って不具合化する場合がある |
特にややこしいのは、Extension Hostが完全に落ちている場合だけでなく、落ちてはいないが応答が遅すぎる場合も似た症状になることです。エラー文に「did not respond within 16 seconds」や「deadline_exceeded」が出る場合、時間内に応答できなかったと考えられます。
この場合、原因は単純なクラッシュだけではありません。巨大なプロジェクトを開いている、ファイル監視が大量に走っている、重い拡張機能が初期化中、CursorのRulesやSkillsが読み込まれている、ネットワーク設定が詰まっている、といった要因も考えられます。
🧭 原因の見分け方マトリクス
| 状況 | 可能性が高い原因 | 最初の対処 |
|---|---|---|
| 起動直後から毎回止まる | 拡張機能・設定破損 | 拡張機能無効化 |
| 更新直後に発生 | Cursor本体の不具合 | バージョン確認 |
| 大きなリポジトリだけ止まる | ファイル監視過多 | .cursorignore 検討 |
| 30〜60秒後に動く | 初期読み込み待ち | 少し待って再実行 |
| どの操作でもタイムアウト | Host応答停止 | ログ確認と設定リセット |
つまり、「AIが遅い」と「Extension Hostが止まっている」は見た目が似ていますが、対処は違います。AI応答が遅いだけなら待てば返る可能性がありますが、Extension Hostが死んでいる場合は、何度プロンプトを送っても同じタイムアウトになります。
Cursor更新直後に出た場合はバージョン不具合の可能性を先に疑うべき
「昨日まで動いていたのに、更新した直後からCursorが待機表示のまま動かない」という場合は、拡張機能だけでなく Cursor本体のバージョン不具合 も疑うべきです。調査したCursorフォーラムでは、2.4.13、2.4.14、2.4.22、2.4.27、2.4.28、2.4.36、2.4.37など、複数バージョンで似た報告がありました。
もちろん、特定バージョンがすべての環境で必ず壊れるとは言えません。OS、拡張機能、ワークスペース、ログイン状態、企業アカウントの制限などが絡むためです。ただし、更新直後に複数ユーザーが同じ症状を報告している場合、ローカル環境だけの問題ではない可能性があります。
Cursor Community Forumでは、あるユーザーが2.4.14で発生した問題について、2.4.7へ戻すと動作したと報告しています。また別のユーザーは2.3.35へ戻したところ解消したと述べています。Linuxではパッケージ管理側のキャッシュが原因で新しいCursorを取得できず、dnf clean all などで更新状態を見直した報告もありました。
このような流れを見ると、更新直後のトラブルでは、次の3点を確認するのが現実的です。
🛠 更新直後に確認すること
| 確認項目 | 内容 |
|---|---|
| 現在のCursorバージョン | Menu → About Cursor → Copy などで確認 |
| 発生タイミング | 更新前からか、更新直後からか |
| 他ユーザー報告 | Cursor Forumなどで同バージョン報告があるか |
| 旧バージョンでの挙動 | 可能なら安定していた版へ戻す |
| 企業アカウント制限 | Early Accessを使えない場合がある |
注意したいのは、ダウングレードは便利な回避策ですが、最初の一手にする必要はないという点です。拡張機能やキャッシュが原因の場合、バージョンを戻しても直らないケースがあります。実際、フォーラム内には「ダウングレードでは直らず、state.vscdb のリネームで解決した」という報告もありました。
そのため、更新直後でも次の順番がおすすめです。まず現在のバージョンをメモし、拡張機能の無効化を試し、ログを確認し、それでも改善しなければキャッシュや設定のリセット、最後にダウングレードを検討します。
📊 バージョン由来かどうかの判断表
| 判断材料 | バージョン由来の可能性 |
|---|---|
| 更新直後から全プロジェクトで発生 | 高め |
| 同じバージョンの報告が複数ある | 高め |
| 拡張機能を無効化しても変わらない | やや高め |
| 設定リセットで直る | プロファイル由来の可能性 |
| 特定拡張機能を外すと直る | 拡張機能由来の可能性 |
参考: Cursorフォーラムでは、更新後に「Waiting for extension host」とタイムアウトが続く報告が複数あります。
https://forum.cursor.com/t/after-last-update-stuck-at-waiting-for-extension-host/149538
拡張機能をすべて無効化して起動できるか確認するのが最短の切り分けである
「waiting for extension host」で最も効率よく原因を分けるなら、まず 拡張機能をすべて無効化してCursorを起動できるか を確認します。なぜなら、Extension Hostは拡張機能を動かす場所なので、どれかひとつの拡張機能が壊れていても全体に影響する可能性があるからです。
Cursorの画面が操作できる場合は、Extensions画面からすべての拡張機能を無効化し、Cursorを再起動します。画面操作すら難しい場合は、一般的には起動オプションで拡張機能を無効化する方法が使われることがあります。ただし、環境によってパスや起動方法が異なるため、ここでは「拡張機能を無効化して起動する」という考え方を優先して説明します。
拡張機能をすべて無効化して問題が消えるなら、原因はかなりの確率で拡張機能側です。この場合は、すべてを一気に戻すのではなく、5〜10個ずつ有効化して再起動します。どのグループで再発するかを見れば、原因候補を絞れます。
🔎 拡張機能の切り分け手順
| 手順 | 作業 | 判定 |
|---|---|---|
| 1 | 全拡張機能を無効化 | 症状が消えるか確認 |
| 2 | Cursorを再起動 | Hostが安定するか見る |
| 3 | 5〜10個ずつ有効化 | 再発するグループを探す |
| 4 | 問題グループを1個ずつ確認 | 原因拡張を特定 |
| 5 | 代替・旧バージョン・無効化を検討 | 再発を避ける |
この方法は地味ですが、かなり実用的です。拡張機能が20個、30個入っている環境で1個ずつ確認すると時間がかかりますが、グループごとに戻す「二分探索」のようなやり方なら早く絞れます。
特にAI系、フォーマッター系、Python/Jupyter系、Git系、大規模な言語サーバーを動かす拡張機能は優先的に疑う価値があります。これらは内部で重い処理やファイル監視を行うため、Extension Hostに負荷をかけやすいからです。
🧪 拡張機能タイプ別の見方
| 拡張機能タイプ | 起こりやすい問題 | 対処の方向 |
|---|---|---|
| フォーマッター | 保存時処理で衝突 | 無効化・旧版利用 |
| Python / Jupyter | 環境検出やカーネル処理が重い | ワークスペース単位で確認 |
| Git関連 | 大きなrepoで負荷 | 対象フォルダ除外 |
| AI補助系 | Cursor機能と競合する可能性 | 併用を見直す |
| テーマ系 | 可能性は低め | 後回しで確認 |
RapidDevの記事でも、Prettier拡張機能やメモリを多く使う拡張機能、破損した拡張機能インストール、大きすぎるワークスペースなどが原因候補として挙げられています。すべての環境に当てはまるわけではありませんが、切り分けの出発点としてはかなり妥当です。
PrettierやJupyterなど重い拡張機能は優先的に確認すべき候補である
拡張機能の中でも、調査上とくに名前が出ていたのが Prettier と Jupyter です。RapidDevの記事では、Prettier v12+のCursor互換性問題が主な原因候補として紹介されています。またGitHubのvscode-jupyter issueでは、Cursor上でJupyter拡張を使った際にExtension Hostが繰り返し落ちたという報告がありました。
ただし、ここで注意したいのは「PrettierやJupyterが必ず悪い」と決めつけないことです。バージョン、OS、Cursor本体、ワークスペースの状態によって変わります。とはいえ、調査情報の中で具体的に名前が挙がっている以上、原因候補として優先的に確認する価値はあります。
Prettierは保存時フォーマットなどで頻繁に動作します。JupyterはPython環境、カーネル、ノートブック、ファイル監視などが絡むため、環境が複雑になりやすいです。どちらも便利な拡張機能ですが、Extension Hostが不安定なときは一度外して確認すると原因を絞りやすくなります。
🧯 優先的に確認したい拡張機能
| 拡張機能・種類 | 理由 | 試すこと |
|---|---|---|
| Prettier | 互換性問題の報告あり | 一時無効化・旧版検討 |
| Jupyter | Python環境やファイル数の影響を受けやすい | 無効化して再起動 |
| Python系 | 環境検出が重い場合がある | 対象プロジェクトを変えて確認 |
| Git系 | 大規模repoで負荷が出る場合 | .git や生成物を除外 |
| AI補助系 | CursorのAI機能と競合する可能性 | 併用を減らす |
GitHub issueでは、「too many file descriptors」に関するエラーが出ていたとの記載もあります。これは一般的には、開いているファイルや監視対象が多すぎるときに出ることがある種類の問題です。Cursor自体の問題というより、ワークスペースや拡張機能の組み合わせで表面化する可能性があります。
大規模プロジェクトを開いている人は、node_modules、dist、build、.git、ログフォルダ、生成物フォルダなどをCursorの対象から外すことも検討できます。.cursorignore のような除外設定を使うと、Cursorが不要なファイルを追いかけにくくなり、負荷を下げられる場合があります。
📁 除外を検討したいフォルダ例
| フォルダ | 除外候補になる理由 |
|---|---|
node_modules |
ファイル数が非常に多い |
dist |
生成物であり編集対象ではないことが多い |
build |
ビルド成果物が大量になりやすい |
.git |
内部ファイルが多く監視負荷になりやすい |
logs |
更新頻度が高い場合がある |
.venv |
Python環境のファイルが多い |
参考: GitHub issueでは、Cursor上でJupyter拡張使用時にExtension Hostが繰り返し停止する報告があります。
https://github.com/microsoft/vscode-jupyter/issues/15729
キャッシュとユーザー設定の破損は再インストールだけでは残ることがある
「Cursorをアンインストールして入れ直したのに直らない」という場合、原因はアプリ本体ではなく、ユーザー設定やキャッシュフォルダに残っているデータかもしれません。これはVS Code系エディタでよくある考え方です。アプリを消しても、ユーザー設定や拡張機能のデータが別フォルダに残る場合があります。
Windowsでは %APPDATA%\Cursor、Macでは ~/Library/Application Support/Cursor/、Linuxでは ~/.config/Cursor/ などが確認対象になります。フォーラムでは、Windowsで globalStorage\state.vscdb をリネームしたら解決したという報告や、Ubuntuで ~/.config/Cursor/ を削除して再起動したら使えるようになったという報告がありました。
ただし、これらの削除やリネームはログイン状態や設定を失う可能性があります。実行する前に、完全削除ではなく リネームして退避 する方が戻しやすいです。たとえば Cursor フォルダを Cursor_backup_20260601 のように名前変更してから起動すれば、必要なら元に戻せます。
🗂 OS別に確認したい場所
| OS | 確認フォルダ例 | 注意点 |
|---|---|---|
| Windows | %APPDATA%\Cursor |
設定・ログ・globalStorageが含まれる場合 |
| Windows | %USERPROFILE%\.cursor |
Cursor関連データがある場合 |
| macOS | ~/Library/Application Support/Cursor/ |
キャッシュやログを確認 |
| Linux | ~/.config/Cursor/ |
設定初期化で改善報告あり |
| Linux | ~/.cursor-server/ |
リモート・サーバー系の問題で関係する場合 |
キャッシュや設定を触る前には、Cursorを完全終了してください。起動中にフォルダを動かすと、ファイルがロックされていたり、中途半端な状態になる可能性があります。また、企業アカウントやチーム設定で管理されている環境では、勝手に消す前に管理者に確認した方がよい場合もあります。
「再インストールで直らない」問題の多くは、アプリ本体だけを入れ替えても、壊れた設定ファイルが残っていることが原因です。これはxcopyや単純なコピーで解決しにくい理由でもあります。壊れた状態をコピーしてしまえば、移動先でも同じ問題が再発する可能性があります。
🧰 設定リセット前の安全手順
| 手順 | 内容 |
|---|---|
| 1 | Cursorを完全終了する |
| 2 | 対象フォルダを削除ではなくリネームする |
| 3 | Cursorを起動してログインし直す |
| 4 | 症状が消えたか確認する |
| 5 | 必要な設定だけ戻す |
参考: エラー大全集では、キャッシュと設定のリセット対象として
%APPDATA%\Cursorや%USERPROFILE%\.cursorが紹介されています。
https://error-daizenn.hatenablog.com/entry/2026/03/21/122420
Why does the cursor take so long to generate?はRulesやSkillsの読み込み待ちも関係する場合がある
「Cursorの生成が遅い」「waiting for extension hostのまま長い」と感じる場合、必ずしも完全に壊れているとは限りません。調査したフォーラムでは、RulesやSkillsの処理中に待ち時間が発生しており、30〜60秒ほど待ってから再試行すると動くという報告もありました。
これは、Cursorがプロンプトを送る前に、プロジェクトルール、スキル、第三者の設定、ワークスペース情報などを読み込んでいる可能性があるためです。もちろん、この説明だけで全ケースを片づけることはできません。16秒でタイムアウトするエラーが出る場合は、単なる読み込み待ちではなくExtension Hostの応答停止も疑うべきです。
見分けるポイントは、待てば動くのか、毎回タイムアウトするのかです。30〜60秒後に再実行して動くなら初期読み込みや負荷の可能性があります。一方、何度やっても「Agent Execution Timed Out」になる場合は、拡張機能や設定の問題へ進んだ方がよいです。
⏱ 待つべきケースと直すべきケース
| 状況 | 判断 | 対処 |
|---|---|---|
| 起動直後だけ遅い | 初期読み込みの可能性 | 30〜60秒待つ |
| Rules/Skills読み込み表示がある | 設定処理中の可能性 | リロードせず待つ |
| 毎回16秒前後で失敗 | Host応答停止の可能性 | 拡張機能を切り分ける |
| どのモデルでも失敗 | モデルではなく内部処理の可能性 | ログと設定を確認 |
| 特定プロジェクトだけ遅い | ファイル数やルール量の影響 | 除外設定を検討 |
ここで焦って何度もReload Windowを押すと、かえって初期化処理を繰り返してしまう可能性があります。フォーラム上にも「Reloadせず、ポップアップを閉じて少し待ってから再試行する」という方向の報告がありました。すべての環境で有効とは限りませんが、起動直後の待機であれば試す価値があります。
ただし、長時間待っても何も変わらない場合は別です。10分以上待つような状態なら、単なる読み込み待ちと見るより、Extension Hostのクラッシュ、設定破損、拡張機能競合、ネットワーク設定の問題を疑う方が自然です。
📌 生成が遅いときの確認順
| 順番 | 確認 |
|---|---|
| 1 | 起動直後かどうか |
| 2 | RulesやSkillsの読み込み表示があるか |
| 3 | 30〜60秒後に再実行して動くか |
| 4 | どのモデルでも同じか |
| 5 | 拡張機能無効化で改善するか |
つまり、「Cursorの生成が遅い」と「waiting for extension hostで詰まる」は重なる部分がありますが、完全に同じではありません。まず短時間待ち、それでもダメなら切り分けへ進む、という二段構えが現実的です。
ポチップ
cursor waiting for extension hostを再発させないための環境チェック
- Does cursor allow extensions?の答えは可能だが互換性と負荷には注意が必要である
- Windowsでは%APPDATA%\CursorのログとglobalStorageを確認すると原因に近づきやすい
- MacとLinuxでは設定フォルダやパッケージ管理のキャッシュも確認対象である
- ネットワーク診断やVPNが絡む場合は通信設定も切り分けるべきである
- 大きなワークスペースでは.cursorignoreで監視対象を減らすと安定しやすい
- ダウングレードは有効な場合があるが設定破損には効かないことがある
- 「cursor waiting for extension host」についてAI回答を見る前にログと症状を整理しておくべき
- 総括：cursor waiting for extension hostのまとめ
Does cursor allow extensions?の答えは可能だが互換性と負荷には注意が必要である
「Does cursor allow extensions?」という関連検索が出る理由は、おそらく「CursorでVS Code拡張機能を使ってよいのか」「拡張機能が原因で壊れるなら使わない方がいいのか」という不安があるからです。結論として、CursorはVS Code系の拡張機能を使える設計ですが、すべての拡張機能がCursorで同じように安定するとは限りません。
CursorはVS Codeをベースにしているため、多くの拡張機能が動きます。しかし、AI Agent、Composer、独自のチャット機能、Rules、Skillsなど、Cursor独自の機能もあります。そのため、VS Codeでは問題ない拡張機能でも、Cursorでは負荷や互換性の問題が表面化する場合があります。
とくに、保存時に動くフォーマッター、ファイル全体を監視する拡張機能、PythonやJupyterのように外部環境と連携する拡張機能、Gitの状態を常に追う拡張機能は、Extension Hostに影響しやすい候補です。便利さと安定性のバランスを見ながら使う必要があります。
🧩 Cursorで拡張機能を使うときの考え方
| 方針 | 内容 |
|---|---|
| 必要なものだけ入れる | 使っていない拡張機能は無効化する |
| 重いものはワークスペース単位で使う | 全プロジェクトで常時有効にしない |
| 更新直後は様子を見る | 拡張機能側の互換性問題を避ける |
| 似た機能を重複させない | 複数フォーマッターやAI補助の競合を避ける |
| 不具合時は一括無効化する | 原因の切り分けを早くする |
拡張機能が使えること自体はCursorの強みです。ただし、AI機能が仕事の中心になっている場合、拡張機能を大量に入れすぎると、かえって安定性を落とす可能性があります。必要最小限にしておく方が、トラブル時の復旧も簡単です。
特に「VS Codeでは問題ないからCursorでも問題ないはず」と考えるのは少し危険です。CursorはVS Codeと似ていますが、AI機能のための独自処理が乗っています。そのため、拡張機能の組み合わせによってはCursorだけで症状が出ることがあります。
🔧 拡張機能運用のおすすめ
| 運用 | メリット |
|---|---|
| 普段使う拡張機能を10〜15個程度に絞る | 原因特定がしやすい |
| フォーマッターは1種類に寄せる | 保存時の衝突を減らせる |
| プロジェクトごとに必要な拡張だけ有効化 | 無駄な負荷を減らせる |
| 更新日はすぐ大量作業に入らない | 不具合時の影響を小さくできる |
| 不具合メモを残す | 再発時に早く戻せる |
Cursorで拡張機能を使うこと自体を避ける必要はありません。ただし、「便利だから全部入れる」より、「必要だから入れる」という運用の方が安定しやすいです。
Windowsでは%APPDATA%\CursorのログとglobalStorageを確認すると原因に近づきやすい
Windowsで「cursor waiting for extension host」が出る場合、まず見たいのは %APPDATA%\Cursor\logs と、設定データが入る globalStorage 周辺です。Cursorフォーラムでは、Windows 10/11環境で更新直後に問題が出た報告があり、さらに state.vscdb をリネームしたら解決したという報告もありました。
state.vscdb はCursorやVS Code系の状態保存に関係するデータベースファイルです。ここが破損したり、古い状態を抱えたまま更新後のCursorと噛み合わなくなったりすると、再起動だけでは改善しない可能性があります。ただし、直接削除するとログイン状態や設定に影響する場合があるため、削除ではなくリネームが無難です。
Windowsでの確認は、次の順番で行うと安全です。
🪟 Windowsで確認する場所
| 場所 | 目的 |
|---|---|
%APPDATA%\Cursor\logs |
エラーやクラッシュログを見る |
%APPDATA%\Cursor\User\globalStorage |
状態保存データを確認する |
%APPDATA%\Cursor\User\globalStorage\state.vscdb |
リネームで改善報告あり |
%USERPROFILE%\.cursor |
Cursor関連データを確認する |
| インストールフォルダ | 本体バージョン確認 |
ログを見るときは、「Extension Host」「error」「timeout」「out of memory」「deadline_exceeded」などの文字を探すと手がかりになります。ログが大量にある場合は、問題が起きた時刻に近いファイルから確認します。
もし state.vscdb を試す場合は、Cursorを完全に閉じたうえで、たとえば state.vscdb.bak のように名前を変えます。その後Cursorを起動し、ログインし直してAI機能が動くか確認します。これで改善するなら、ユーザー状態データの不整合が関係していた可能性があります。
⚠️ Windowsで作業する前の注意点
| 注意 | 理由 |
|---|---|
| Cursorを閉じてから作業する | ファイル破損やロックを避ける |
| 削除ではなくリネームする | 元に戻せるようにする |
| ログイン情報が消える可能性を理解する | 再ログインが必要になる場合がある |
| 会社PCでは管理者に確認する | ポリシー違反を避ける |
| 作業前にパスをメモする | 戻すときに迷わない |
エラー大全集の記事では、Windows 11環境でExtension Host Errorが繰り返される場合、拡張機能の完全無効化、キャッシュと設定のリセット、ネットワーク設定の確認、クリーンインストール、ダウングレードが対処候補として整理されています。
WindowsではセキュリティソフトやWindows Defender、プロキシ設定、VPNも絡むことがあります。特に「Network Diagnostics」を実行したタイミングで問題が見える場合は、通信まわりも切り分け対象に入れるべきです。
MacとLinuxでは設定フォルダやパッケージ管理のキャッシュも確認対象である
MacやLinuxでも「waiting for extension host」は報告されています。CursorフォーラムではMacOS、Linux Mint、Ubuntuなどで似た症状の報告がありました。Windowsだけの問題と考えるのは早いです。
Macでは ~/Library/Application Support/Cursor/、Linuxでは ~/.config/Cursor/ が主な確認対象です。Ubuntuでは ~/.config/Cursor/ を削除して再起動したら動いたという報告がありました。削除ではなくリネームで試せば、戻す余地を残せます。
Linuxではもうひとつ、パッケージ管理のキャッシュ問題もありえます。フォーラムでは、DNFが新しいCursorパッケージを正しく見つけられないように見えるケースで、dnf clean all や dnf check-update が役立ったという報告がありました。これはExtension Hostそのものというより、更新状態が正しく反映されない問題です。
🐧 Mac・Linuxで確認したい項目
| OS | 確認場所・操作 | 目的 |
|---|---|---|
| macOS | ~/Library/Application Support/Cursor/ |
設定・ログ・キャッシュ確認 |
| macOS | アプリ版のバージョン確認 | 更新直後の不具合判定 |
| Linux | ~/.config/Cursor/ |
設定初期化の確認 |
| Linux | ~/.cursor-server/ |
リモート・サーバー系の確認 |
| Linux | パッケージ管理キャッシュ | 更新不整合の確認 |
Macではアプリをゴミ箱に入れて再インストールしても、Application Support配下の設定が残ることがあります。Linuxでもアプリ本体とユーザー設定は別です。つまり、どのOSでも「本体を入れ直したのに直らない」場合は、設定フォルダの不整合を疑う価値があります。
LinuxでCursorをdebやrpmで管理している場合、リポジトリ側の反映タイミングやキャッシュによって、思ったバージョンに上がらないことがあります。バージョン不具合を疑っているのに実際には古い版のままだと、切り分けが混乱します。必ずインストール済みバージョンを確認しましょう。
📦 Linuxでバージョン確認時に見ること
| 見る項目 | 理由 |
|---|---|
| インストール済みCursorのバージョン | 実際に使っている版を確認する |
| リポジトリに見えている最新版 | 更新候補が正しいか見る |
| CPUアーキテクチャ | x86_64 / arm64の不一致を避ける |
| キャッシュ状態 | 古い情報を見ていないか確認する |
| 旧バージョンの入手可否 | ダウングレードできるか確認する |
MacやLinuxでは、ターミナル操作に慣れている人ほど一気に削除したくなるかもしれません。しかし、Cursorの設定フォルダにはログイン状態や設定が含まれることがあります。復旧目的なら、まずリネームで検証する方が安全です。
ネットワーク診断やVPNが絡む場合は通信設定も切り分けるべきである
Extension Hostの問題は拡張機能やキャッシュだけでなく、ネットワーク設定が絡む場合もあります。特に、エラー大全集の記事では「Network Diagnostics」で問題が顕在化するケースや、VPN、プロキシ、ファイアウォール、hostsファイルの確認が対処候補として挙げられています。
ただし、ネットワークだけが原因なら、通常は「AIサービスへ接続できない」「API通信に失敗する」といった見え方になることも多いです。一方、「waiting for extension host」は内部プロセスの問題に見えます。そのため、ネットワークは最初の原因と決めつけるより、拡張機能と設定を見た後、またはNetwork Diagnosticsで異常がある場合に確認するのが自然です。
VPNを使っている場合は、一度オフにしてCursorを再起動します。企業プロキシやセキュリティソフトを使っている環境では、Cursorの通信が制限されている可能性があります。特に会社PCや学校PCでは、管理者側のポリシーが関係する場合があります。
🌐 ネットワーク切り分けチェック
| 確認項目 | 試すこと |
|---|---|
| VPN | 一時的にオフにして再起動 |
| プロキシ | OS設定・Cursor設定を確認 |
| ファイアウォール | Cursorの通信が止められていないか確認 |
| Windows Defender | 例外設定や履歴を確認 |
| hostsファイル | 不自然なブロック設定がないか確認 |
| 別回線 | スマホテザリングなどで比較 |
通信設定が原因かどうかは、別ネットワークで試すと分かりやすいです。たとえば自宅Wi-Fiでダメでもスマホテザリングなら動く場合、ネットワークやDNS、プロキシ、ファイアウォールが関係している可能性があります。反対に、どの回線でも同じならローカルの設定や拡張機能を疑います。
ネットワーク診断で異常が出たからといって、Extension Hostの原因が必ず通信だとは言えません。通信失敗がトリガーになって拡張機能が不安定になる場合もあれば、Extension Hostが落ちているから診断が正しく動かない場合もあるためです。
🧭 通信由来かローカル由来かの見分け方
| 状況 | 可能性 |
|---|---|
| 別回線で改善する | ネットワーク由来の可能性 |
| VPNオフで改善する | VPN・プロキシ由来の可能性 |
| 拡張機能無効化で改善する | ローカル拡張由来の可能性 |
| 設定リセットで改善する | プロファイル破損の可能性 |
| どれでも改善しない | バージョン不具合や深い環境問題の可能性 |
ネットワーク設定を触る場合も、元に戻せるように変更前の状態をメモしておくと安心です。特にプロキシやhostsファイルは、別の業務ツールに影響することがあります。
大きなワークスペースでは.cursorignoreで監視対象を減らすと安定しやすい
大きなプロジェクトをCursorで開いている場合、Extension Hostが大量のファイルを監視して重くなることがあります。RapidDevの記事でも、ワークスペースにファイルが多すぎると、ファイル監視系の拡張機能がHostプロセスを圧迫する可能性があるとされています。
特にWeb開発やPython開発では、node_modules、.venv、dist、build、.git、キャッシュ、ログなど、編集しないのに大量のファイルが存在するフォルダがあります。これらをCursorや拡張機能が追いかけると、起動時やAI実行時に負荷が高くなることがあります。
その対策として、.cursorignore のような除外ファイルを使い、Cursorに見せる必要がないフォルダを除外する方法があります。すべての問題がこれで解決するわけではありませんが、巨大リポジトリや生成物が多い環境では効果が出る可能性があります。
📁 .cursorignoreで除外を検討する対象
| 対象 | 理由 |
|---|---|
node_modules/ |
ファイル数が非常に多い |
.git/ |
内部データが多く変更も多い |
dist/ |
生成物でありAI編集対象外になりやすい |
build/ |
ビルド成果物が多い |
.venv/ |
Python仮想環境のファイルが多い |
logs/ |
更新頻度が高い場合がある |
.cache/ |
一時ファイルが多い |
ただし、除外しすぎるとCursorのAIが必要な文脈を読めなくなる場合があります。たとえば、実際に編集対象のソースコードまで除外してしまうと、AIの回答精度が下がる可能性があります。除外するのは、基本的に「生成物」「依存パッケージ」「キャッシュ」「ログ」に絞るのが無難です。
また、ファイル数の多さだけでなく、頻繁に更新されるファイルも負荷になります。ログが秒単位で更新される、ビルド成果物が大量に書き換わる、監視タスクが裏で走っている、といった環境では、Extension Hostが忙しくなりやすいです。
🧮 除外判断の目安
| フォルダの種類 | 除外判断 |
|---|---|
| 自分が編集するソース | 除外しない |
| 外部依存パッケージ | 除外候補 |
| 自動生成ファイル | 除外候補 |
| ビルド成果物 | 除外候補 |
| 設定ファイル | 基本は除外しない |
| ドキュメント | AIに読ませたいなら除外しない |
大きなワークスペースでだけ「waiting for extension host」が出るなら、拡張機能そのものより、開いているフォルダの規模が原因かもしれません。別の小さなフォルダを開いてCursorが安定するか試すと、判断しやすくなります。
ダウングレードは有効な場合があるが設定破損には効かないことがある
Cursorの更新直後に「waiting for extension host」が出る場合、ダウングレードは有効な回避策になることがあります。フォーラムでは、2.4.7や2.3.35へ戻して改善したという報告がありました。Linux Mintでも2.4.36や2.4.37で問題があり、2.3.35で動いたという報告があります。
ただし、ダウングレードは万能ではありません。別のユーザーは、いろいろなバージョンに戻しても改善せず、state.vscdb をリネームして解決したと報告しています。つまり、原因がCursor本体ではなくユーザー設定やキャッシュ側にある場合、バージョンを戻しても同じ壊れた状態を読み込んでしまう可能性があります。
そのため、ダウングレードは次のような条件で検討するとよいです。
🔁 ダウングレードを検討する条件
| 条件 | 判断 |
|---|---|
| 更新直後から発生 | 検討価値あり |
| 同じバージョンの不具合報告がある | 検討価値あり |
| 拡張機能無効化でも直らない | 検討価値あり |
| 設定リセットでも直らない | 検討価値あり |
| 旧版で安定していた記録がある | 戻す候補にしやすい |
反対に、次のような場合はダウングレードより先に別の確認をした方がよいです。特定プロジェクトだけで発生するならワークスペース負荷、特定拡張機能を入れてから発生したなら拡張機能、ログにキャッシュやDB系のエラーがあるなら設定リセットが優先です。
ダウングレードする場合は、必ず現在のバージョンをメモしておきましょう。旧版で直るかどうかは重要な情報です。後でCursor Forumやサポートに報告する場合にも、「どのバージョンで発生し、どのバージョンで改善したか」があると話が早くなります。
📌 ダウングレード前に残すメモ
| メモ項目 | 例 |
|---|---|
| 現在のCursorバージョン | 2.4.xxなど |
| OS | Windows 11 / macOS / Ubuntuなど |
| 発生タイミング | 更新直後、拡張追加後など |
| エラーメッセージ | Agent Execution Timed Outなど |
| 試した対処 | 拡張無効化、設定リセットなど |
| 旧版での結果 | 改善・変化なし |
バージョンを戻すときは、公式の配布元や信頼できる入手経路を使うべきです。非公式ミラーや出所不明のインストーラーは、別のリスクが出ます。企業アカウントではEarly Accessや旧版利用が制限される場合もあるため、その点も確認しましょう。
「cursor waiting for extension host」についてAI回答を見る前にログと症状を整理しておくべき
関連検索には「『cursor waiting for extension host』について AI回答を見る」という意図もあります。AIに質問すること自体は便利ですが、質問前に症状を整理しておくと、回答の質が大きく変わります。なぜなら、この問題は原因候補が多く、情報が少ないと一般論しか返ってこないからです。
最低限、Cursorのバージョン、OS、発生タイミング、エラーメッセージ、試した対処、入れている主な拡張機能、問題が出るプロジェクトの規模をまとめておくと、かなり具体的な切り分けができます。ログの該当部分があれば、さらに判断しやすくなります。
AIに聞く前に、次のテンプレートを埋めるとよいです。
📝 質問前の整理テンプレート
| 項目 | 記入例 |
|---|---|
| OS | Windows 11 |
| Cursorバージョン | 2.4.xx |
| 発生タイミング | 更新直後から |
| 表示エラー | waiting for extension host / Agent Execution Timed Out |
| 影響範囲 | Agent、Ask、Composerすべて |
| 試したこと | 再起動、拡張無効化、ログ確認 |
| 主な拡張機能 | Prettier、Python、Jupyterなど |
| プロジェクト規模 | node_modulesあり、大きめrepo |
この情報がないまま「直し方を教えて」と聞くと、再起動、再インストール、拡張機能無効化といった一般的な回答になりがちです。もちろんそれでも入口にはなりますが、すでに試したことを繰り返すだけになる可能性があります。
ログを貼る場合は、個人情報やパス、トークン、会社名、プロジェクト名が含まれていないか確認しましょう。特にCursorのログにはローカルパスや拡張機能名が含まれる場合があります。公開フォーラムや外部AIに貼るなら、必要な部分だけに絞るのが安全です。
🔐 ログ共有時の注意点
| 注意点 | 理由 |
|---|---|
| ユーザー名を伏せる | ローカルパスに含まれる場合がある |
| APIキーを貼らない | 認証情報漏えいを避ける |
| 会社名・顧客名を隠す | 業務情報の流出を避ける |
| エラー周辺だけ貼る | 不要な情報を減らす |
| 試した対処を添える | 重複回答を避ける |
AI回答は便利ですが、最終的には自分の環境で切り分ける必要があります。この記事の順番に沿って「どこまで試したか」を整理してから質問すると、より現実的な回答が得られやすくなります。
総括：cursor waiting for extension hostのまとめ
最後に記事のポイントをまとめます。
cursor waiting for extension hostは、CursorのAIモデル自体ではなくExtension Hostの応答停止で起きることが多い。- Extension Hostは拡張機能を動かす内部プロセスであり、止まるとAI機能も巻き込まれる。
- 最初に試すべき対処は、Cursor再起動ではなく拡張機能の一括無効化による切り分けである。
- 拡張機能を無効化して直る場合は、5〜10個ずつ戻して原因候補を絞るのが効率的である。
- Prettier、Jupyter、Python、Git系、AI補助系の拡張機能は優先的に確認する候補である。
- Cursor更新直後に発生した場合は、本体バージョン不具合の可能性も考えるべきである。
- ダウングレードで改善する例はあるが、設定破損やキャッシュ破損には効かない場合がある。
- Windowsでは
%APPDATA%\Cursor\logsやglobalStorage\state.vscdb周辺の確認が有効な場合がある。 - Macでは
~/Library/Application Support/Cursor/、Linuxでは~/.config/Cursor/が確認対象である。 - 再インストールだけではユーザー設定やキャッシュが残り、同じ症状が続くことがある。
- 大きなワークスペースでは
node_modules、dist、build、.gitなどの除外を検討すべきである。 - 起動直後だけ遅い場合はRulesやSkillsの読み込み待ちの可能性があり、30〜60秒待つ判断も必要である。
- VPN、プロキシ、ファイアウォール、hostsファイルなど通信設定も、Network Diagnosticsで異常が出る場合は確認対象である。
- AIに質問する前に、OS、Cursorバージョン、発生タイミング、エラー文、試した対処、拡張機能一覧を整理すべきである。
- 復旧は、拡張機能、ログ、キャッシュ、設定、バージョン、ネットワークの順で切り分けるのが現実的である。
- https://forum.cursor.com/t/after-last-update-stuck-at-waiting-for-extension-host/149538
- https://www.rapidevelopers.com/ai-build-errors/extension-host-terminated-unexpectedly
- https://error-daizenn.hatenablog.com/entry/2026/03/21/122420
- https://www.reddit.com/r/cursor/comments/1qjkx3z/the_agent_execution_provider_did_not_respond/
- https://github.com/microsoft/vscode-jupyter/issues/15729
- https://www.threads.com/@a866662/post/DXLX8HBmWsj/%E6%9C%80%E8%BF%91%E8%B7%91cursor%E4%B8%80%E7%9B%B4%E5%8D%A1%E5%9C%A8waiting-for-extension-host%E6%88%91%E6%87%B7%E7%96%91%E4%BB%96%E6%98%AF%E8%A6%81%E7%9C%81token%E6%89%8D%E4%B8%80%E7%9B%B4%E5%8D%A1%E4%BA%BA
- https://wenku.csdn.net/answer/5b33fu56903d
- https://www.reddit.com/r/cursor/comments/1hlva58/extension_host_error/
- https://blog.csdn.net/weixin_44009697/article/details/151322203
各サイト運営者様へ
有益な情報をご公開いただき、誠にありがとうございます。
感謝の意を込め、このリンクはSEO効果がある形で設置させていただいております。
※リンクには nofollow 属性を付与しておりませんので、一定のSEO効果が見込まれるなど、サイト運営者様にとってもメリットとなれば幸いです。
当サイトは、インターネット上に散在する有益な情報を収集し、要約・編集してわかりやすくお届けすることを目的としたメディアです。
引用や参照の方法に不備、あるいはご不快に感じられる点がございましたら、お問い合わせフォームよりご連絡ください。
今後とも、どうぞよろしくお願いいたします。
