CursorのMCPで「Client closed」が出る原因と対処法
AIエージェントナビ編集部
CursorでMCP（Model Context Protocol）サーバーを設定したのに、設定画面やログに「Client closed」と出て使えないとき、この文言は原因ではありません。Cursorとサーバーのあいだの通信が切れた、という結果を伝えているだけです。
本当の原因は、ログでClient closedのすぐ上の行に出ています。本記事では、MCP Logsでその行を見つける方法と、原因の型ごとに直す場所を整理します。
Cursorの「Client closed」とは
サーバーとの通信が切れたという表示
CursorはMCPサーバーを自分の中で起動し、標準入出力（stdin・stdout）という通信路でやり取りします。サーバーが起動できなかったり、起動直後に終了したりしてこの通信路が閉じると、Cursorは「Client closed」と記録します。
同じClient closedでも、コマンドが見つからない・認証で止まった・途中で落ちたと中身は違うため、文言だけで探した対処法では直らないことがあります。
原因は直前のログに出ている
実際のログでは、Client closedの前に失敗の理由が1行出ています。macOSでFirecrawlのMCPサーバーが動かなかった利用者の記録（2025年3月）では、ログは次の順に並んでいました。
Client error for command A system error occurred (spawn npx ENOENT) Client closed for command Error in MCP: Client closed No server info found
1行目の spawn npx ENOENT が本当の原因で、バージョン管理ツール（mise）で入れたnpxをCursorが見つけられていませんでした。同じ並びは2025年11月以降のフォーラム投稿にも出ています。
MCP Logsで原因を見つける
MCP Logsの開き方
Cursorの公式ドキュメントは、MCPのトラブルを調べる場所としてOutputパネルの「MCP Logs」を案内しています。開き方は次の2手順です。
- Outputパネルを開く（macOSは
Cmd+Shift+U、Windows・LinuxはCtrl+Shift+U）。 - パネルのドロップダウンから「MCP Logs」を選ぶ。
ここにはサーバーの起動、ツールの呼び出し、エラーが時刻つきで流れます。
Client closedの直前の行を読む
MCP Logsで「Client closed」を見つけたら、同じサーバー名の行を上へたどり、最初に [error] や英語のエラー文が出ている行を探します。読むときの目安は次の3つです。
ENOENTやnot recognizedがあれば、コマンドが見つかっていません。authenticationやAuthorizationがあれば、認証情報が渡っていません。- サーバー自身のエラー文（スタックトレースなど）があれば、サーバー側で落ちています。
サーバーが自分で出したエラー出力（stderr）も、このログに転送されます。
Next version (51) will have stderr properly redirected to mcp output logs（訳）次のバージョン（0.51）から、stderr（エラー出力）がMCPの出力ログに正しく送られるようになります。
これは閲覧数2万6,000を超えるフォーラムのスレッドでCursorのスタッフが2025年5月に答えたもので、それより古い版ではサーバーのエラーがログに出ていませんでした。
見つけた1行が、次の章のどの型に当たるかを決める手がかりになります。
ターミナルで同じコマンドを動かして比べる
次に、mcp.json の command と args を空白でつないだコマンドを、ターミナルでそのまま実行します。エラーが出ずに何も表示されないまま止まって見えれば、サーバーは正常に起動して入力を待っている状態です（Ctrl+C で止めます）。
ターミナルでは動くのにCursorからは動かないなら、Cursorから見えるPATHや環境変数がターミナルと違うことを疑います。ターミナルでも同じエラーなら、コマンドやサーバーそのものの問題です。
原因の型と直す場所
利用者の報告とCursorのスタッフの回答から、Client closedの前に出ている原因は主に5つの型に分けられます。
| 原因の型 | 見分ける手がかり | 直す場所 |
|---|---|---|
| コマンドが見つからない | ログに spawn npx ENOENT |
mcp.json の command（フルパスで書く） |
| Windowsの実行制限 | Get-ExecutionPolicy が Restricted を返す |
PowerShellの実行ポリシー |
| WSL2でWindows側から起動 | npx is not recognized と出る報告 |
command を wsl.exe 経由にする |
| 認証情報・環境変数が渡らない | ログに authentication required や Authorization header is badly formatted |
env・envFile・headers とCursorの起動方法 |
| サーバーが通信路に余計な文字を出す | 自作・改造したサーバーで起きうる | サーバーのコード（ログはstderrへ） |
コマンドが見つからない
最も多いのが、command に書いた npx や node をCursorが見つけられない型です。Cursorの公式ドキュメントは、command について次のように書いています。
Must be available on your system path or contain its full path.（訳）システムのパスから見つけられるか、フルパスを含んでいる必要があります。
nvmやmise、Homebrewで入れたNode.jsは、ターミナルからは見えてもCursorからは見えないことがあります。npxの場所の調べ方、フルパスの書き方、Windowsでの書き方は、同じエラーを扱った次の記事で手順ごとに解説しています。
関連記事：spawn npx ENOENTでMCPが起動しない原因と対処法
Windowsでスクリプトの実行が止められている
Windowsでは、PowerShellのスクリプト実行ポリシーが原因になることがあります。Windows×Figma MCPでClient closedが消えなかった利用者の記録では、Node.jsを入れても変わらず、ポリシーが Restricted（制限付き）だったことが原因でした。
この利用者は、管理者として開いたPowerShellで Get-ExecutionPolicy を実行して状態を確かめ、RemoteSigned に変えたところ接続できたと報告しています。実行ポリシーはPC全体の安全設定に関わるため、会社のPCでは変更する前に管理者に確認してください。
WSL2でWindows側から起動してしまう
WSL2で開発している場合、CursorはWindowsのアプリとして動いているため、MCPサーバーの起動コマンドもWindows側で実行されることがあります。WSLの中にだけNode.jsを入れていると、Windows側からはnpxが見つからずに止まります。
Cursorのスタッフは2025年5月にWSL内での起動の修正を予告しましたが、WSLのスレッドではその後もWindows側で起動される報告が続いています。2025年11月の投稿では、command を wsl.exe にし、args で bash -lc を通してnvmを読み込んでからnpxを実行する書き方で動いたと報告されています。
"command": "wsl.exe", "args": ["bash", "-lc", "source ~/.nvm/nvm.sh; npx -y サーバーのパッケージ名"]
これは公式の案内ではなく、利用者の投稿で効いたと報告されている方法です。
認証情報や環境変数がサーバーに渡っていない
APIキーやトークンが必要なサーバーは、認証で失敗するとすぐに終了し、その後にClient closedが記録されます。2026年2月のフォーラムの例では authentication required の直後にClient closedが出ており、Cursorのスタッフは「Cursorは mcp.json のコマンドを実行しているだけで、認証の失敗はサーバー側から来ている」と答えています。
見落としやすいのが、${env:NAME} で環境変数を参照している場合です。GitHub MCPの質問へのスタッフの回答（2026年4月）は、最も多い原因を「Cursorの起動時にその環境変数が見えていないこと」としています。確かめ方は次の通りです。
- ターミナルで
echo $変数名を実行し、値が入っているか確かめる。 - そのターミナルから
cursorコマンドでCursorを起動し、接続し直す。 - それで動くなら、Dockやスタートメニューから起動したCursorに変数が届いていない。
stdioサーバーなら、envFile で .env ファイルから読ませる方法もあります。ただし公式ドキュメントによれば、envFile はHTTP・SSEのリモートサーバーでは使えません。
サーバーが通信路に余計な文字を出している
自分で作ったサーバーや手を加えたサーバーでは、コードの書き方が原因になることもありえます。MCPの仕様（2026-07-28版）は、stdout（標準出力）の使い方を次のように定めています。
The server MUST NOT write anything to its stdout that is not a valid MCP message.（訳）サーバーは、正しいMCPメッセージ以外のものをstdoutに書いてはならない。
デバッグ用に console.log や print で標準出力へ文字を出すと、Cursorはそれをメッセージとして読めず、通信が成り立たなくなるおそれがあります。同じ仕様はログをstderr（エラー出力）へ書くことを認めているので、デバッグ用の出力はstderrへ移します。
設定を直しても途中で落ちるとき
作業中にmcp.jsonを書き換えない
一度はつながったのに、作業の途中でClient closedに戻る場合もあります。Cursorのスタッフは2026年7月の回答で、作業中に mcp.json を編集すると接続がいったん切られて作り直されるため、作業中の編集は避けるよう案内しています。設定を変えるときは、手を止めてからまとめて保存します。
再接続の繰り返しで落ちる報告
stdioサーバーが作業中に何度も落ちるというOracle SQLclの報告（2026年7月）に対し、スタッフは、stdioサーバーの二重起動や並行した再接続は報告を把握している問題だと答えています。サーバー側の作りと重なって起きるもので、mcp.json の設定で止める項目は今のところないとのことです。
なお公式ドキュメントによれば、1つのサーバーが落ちても、ほかのMCPサーバーは動き続けます。
トグルでオフ・オンして接続し直す
落ちたサーバーは、そのままにしておくとすぐには復帰しません。同じスタッフの回答は、その理由を次のように説明しています。
a dead stdio server otherwise only retries on a slow timer.（訳）（トグルで入れ直さなければ）落ちたstdioサーバーは、遅い間隔でしか再試行されません。
サイドバーの「Customize」を開き、該当するサーバーのトグルをオフにしてからオンに戻すと、すぐに接続し直されます。設定を消さずに止められるので、原因のサーバーを1台ずつ切り分けるときにも使えます。
まとめ
CursorのClient closedは、MCPサーバーとの通信が切れたという結果の表示です。原因は、MCP Logsでその直前に出ている1行にあります。
spawn npx ENOENTなら、commandをフルパスにする。- Windowsなら、PowerShellの実行ポリシーを確かめる。
- WSL2なら、
wsl.exe経由で起動する書き方を試す。 - 認証のエラーなら、環境変数がCursorに届いているかをターミナルから起動して確かめる。
- 作業中に落ちるなら、トグルのオフ・オンで接続し直す。
次にClient closedが出たら、まずMCP Logsを開き、その上の行をコピーしてから対処を選んでください。
