「No LSP server available」の原因と直し方 — Claude Code
設定を何度見直しても消えない「No LSP server available」の原因はワークスペースの未信頼・拡張子の競合・設定スキップ・LSPマネージャーの競合状態の4種類です。切り分け方をまとめます。
「No LSP server available」の原因と直し方 — Claude Code
Claude CodeのLSPツールを使おうとしてNo LSP server available for file type: .tsのようなエラーだけが返ってくることがあります。プラグインの設定は疑って当然です。ただし.lsp.jsonもインストール済みプラグインの登録もenabledPluginsも何度確認しても正しいのに直らないケースが実際に報告されています。本稿は、設定ミス以外に疑うべき3つの原因と、Anthropicのissueトラッカーで確認された既知の競合状態を扱います。
「No LSP server available」が返る場面
このエラーは、LSPツールにdocumentSymbol・hover・findReferences・goToDefinitionといった操作を渡したときに返ります。対象ファイルの拡張子に対応する言語サーバーが1つも見つからない場合の応答です。エラー文はファイル種別ごとに変わり、PythonならNo LSP server available for file type: .py、TypeScriptなら.tsという具合です。
このエラー自体は「言語サーバーが未起動」という事実を正確に伝えているだけで、原因を特定するものではありません。原因は大きく分けて4種類あり、それぞれ切り分け方が異なります。
原因1: ワークスペースを信頼していない
公式のプラグインリファレンスは「LSPサーバーはワークスペースを信頼した後にしか起動しない」と明記しています。プラグインのインストール・有効化・言語サーバーのバイナリ導入がすべて正しくても、そのディレクトリでワークスペースの信頼プロンプトに答えていなければLSPサーバーは起動しません。
ワークスペースの信頼は、そのディレクトリを初めて開いたときに表示される確認プロンプトに答えることで完了します。プロンプトへの回答を後回しにしたまま作業を始めた場合や、CI・コンテナのように対話プロンプトを出せない環境で信頼設定の自動化を忘れた場合、/pluginの画面ではプラグインが「Enabled」のままLSPサーバーだけが起動しません。設定ファイルをいくら見直しても異常が見当たらないのに動かない、という状況を作る典型例です。
原因2: 同じ拡張子を複数のLSPプラグインが宣言している
複数のLSPプラグインが同じ拡張子をextensionToLanguageに宣言している場合、先に登録されたプラグインだけがその拡張子を処理し、残りは起動すらしません。公式ドキュメントによれば、この場合/pluginの画面にどのプラグインが有効になっているかを示す警告が出ますが、見落としやすい表示です。
たとえば独自のRust向けLSPプラグインを自作し、公式マーケットプレイスのrust-analyzer-lspと両方を有効化したとします。両方が.rsを宣言していると、先に登録された側だけが起動し、もう一方は待機状態のまま動きません。原因が自分の設定ではなく、拡張子を先に掴んだ別のプラグイン側にあるケースです。なお、Claude Code v2.1.205より前のバージョンには、先に登録された側の設定にcommandの誤りやバイナリ未検出のような問題を抱えていると、拡張子を占有したまま機能しないサーバーだけが残り、後から登録された正しい設定のプラグインが.rsを処理する機会を得られないという不具合がありました(v2.1.205で修正済み。現在のバージョンでは、先に登録されたサーバーが初期化に失敗しても、同じ拡張子を宣言する別プラグインの正常なサーバーが代わりに起動します)。自作のLSPプラグインと公式マーケットプレイスのプラグインを併用しているときに起きやすく、Claude Codeプラグインに独自のLSPサーバーを組み込む手順で拡張子の割り当てを再確認すると解消することがあります。
原因3: restartOnCrash・shutdownTimeoutと古いバージョンの組み合わせ
.lsp.jsonにrestartOnCrashやshutdownTimeoutを設定している場合に注意します。Claude Code v2.1.205より前のバージョンではこの2つのオプションを解釈できず、該当のLSPサーバーを起動時にまるごとスキップします。設定スキーマ自体は古いバージョンでも受け付けるため、JSONの構文エラーは出ません。No LSP server availableだけが返る厄介な組み合わせです。スキップされた理由はclaude --debugのログにしか出ません。対象言語のプラグインだけがv2.1.205以降で追加した設定項目を使っている場合、この原因を疑います。
なお、$PATH未設定・メモリ消費・モノレポの誤検知・キャッシュ破損は設定起因のつまずきです。これらはClaude Codeのコードインテリジェンス(LSP)活用ガイドの「よくあるトラブルと対処」にまとめてあります。本稿はそれらを一通り確認しても直らない場合の、より根の深い原因を扱います。
原因4: LSPマネージャーとプラグイン読み込みの競合状態(issue #14803)
2025年12月、公式ドキュメントどおりに設定していても解消しないバグが報告されました。.lsp.json・installed_plugins.json・enabledPluginsのすべてが正しく、言語サーバーのバイナリも$PATHから見えている状態でNo LSP server availableが返り続けるという内容です。issue #14803には、Python・TypeScript・Go・Rust・Swift・Java・C/C++と言語を問わず20件近いコメントが集まりました。
コミュニティがnpxで複数バージョンを実行し比較した結果、原因が判明しました。Claude Code v2.0.67のデバッグログでは、LSPマネージャーの初期化処理getAllLspServers()がプラグインの読み込み完了を待ってから3個のサーバーを登録していました。ところがv2.0.76のログでは、プラグインの読み込みが完了する1ミリ秒前にLSPマネージャーが「0個のサーバーで初期化完了」と記録していました。非同期化によって、LSPマネージャーがプラグインの読み込みを待たずに完了してしまう競合状態です。
# v2.0.67(正常)
03:21:22.303Z [LSP SERVER MANAGER] Calling getAllLspServers()
03:21:22.331Z Loading plugin typescript-lsp from source: "./plugins/typescript-lsp"
03:21:22.489Z Total LSP servers loaded: 3
# v2.0.76(不具合あり)
03:19:54.709Z LSP notification handlers registered successfully for all 0 server(s)
03:19:54.710Z Loading plugin typescript-lsp from source: "./plugins/typescript-lsp"Anthropicのエンジニアであるbcherny氏は2025年12月24日のコメントで修正の着手を明言しました。設定を何度見直しても解消しない場合、この競合状態が原因だった可能性があります。
issueの「Requested Fix」欄では、LSPサーバーの起動状況を一覧できる/lspのようなステータスコマンドの追加も要望されていました。要望どおりの/lspコマンドは実装されていません。ただしv2.1.142(2026年5月14日)でclaude plugin detailsと/pluginの詳細画面が、そのプラグインが提供するLSPサーバー一覧を表示するようになりました。近い方向の改善が後から入った形です。
発生バージョンと修正が入ったバージョン
コミュニティの報告と公式changelogを突き合わせると、影響範囲と修正のタイミングは次のとおりです。
| バージョン | リリース日 | 状態 |
|---|---|---|
| v2.0.67 | リリース日ー | 状態最後に正常動作していたと確認されたバージョン |
| v2.0.69〜v2.0.76 | リリース日2025年12月 | 状態競合状態の発生が複数ユーザーで確認された範囲 |
| v2.1.0 | リリース日2026年1月7日 | 状態「LSPツールが起動中に'no server available'を返す競合状態を修正」と明記 |
| v2.1.76 | リリース日2026年3月14日 | 状態「LSPマネージャーがマーケットプレイスの整合前に初期化され、プラグインのサーバーを登録しない不具合を修正」と明記 |
| v2.1.205 | リリース日2026年7月8日 | 状態restartOnCrash・shutdownTimeoutをサポート開始(それ以前は設定するとサーバーを丸ごとスキップ)。初期化に失敗したプラグインのLSPサーバーが、同じ拡張子を宣言する別プラグインの正常なサーバーの起動を妨げる不具合も修正 |
v2.1.0の修正内容は、coygeek氏らが特定した「LSPマネージャーがプラグイン読み込み前に初期化を終える競合状態」と一致します。ただしv2.1.76ではこれとは別に「マーケットプレイスの整合待ち」に起因する類似の未登録も修正されており、プラグイン読み込みまわりのタイミング問題は1回の修正では終わらなかったことが分かります。プラグインの読み込みとキャッシュの関係はClaude Codeプラグインのキャッシュとファイル解決の仕組みで扱っています。
今すぐ試せる対処
まずclaude --versionでインストール済みのバージョンを確認します。v2.1.76より前であれば、アップデートだけで解消する可能性があります。
claude --version
npm install -g @anthropic-ai/claude-code@latestissue #14803が荒れていた期間、コミュニティは公式修正を待ちませんでした。npx経由でv2.0.67を指定実行する回避策や、Piebald-AI/claude-code-lspsという初期化順序を書き換える非公式パッチ(npx tweakcc --applyで適用)がその代表です。いずれも公式の修正が入る前の一時しのぎで、Anthropicが検証したものではありません。v2.1.76以降が入手できる状況なら、アップデートのほうが素直な解決策です。
このバグかどうかを切り分けるチェックリスト
アップデートしても解消しない、あるいはすでに最新版を使っている場合は、次の順で切り分けます。
claude --versionでバージョンを確認し、v2.1.76以降であることを確かめる- 対象ディレクトリでワークスペースの信頼プロンプトに答え済みか確認する(原因1)
claude plugin details <plugin-name>で、そのプラグインが実際にどのLSPサーバーを提供しているかを確認する。/pluginのInstalledタブと合わせて、同じ拡張子を宣言する別のプラグインが有効になっていないかも見る(原因2)。v2.1.205未満では、先に登録された側の設定が壊れていると拡張子ごと機能しなくなることがある点も確認する.lsp.jsonにrestartOnCrash・shutdownTimeoutを設定している場合は一旦外して再現するか試す(原因3)claude --debugを付けて起動し、--debugと--debug-fileの使い分けを参考にログを取得する
ログではLoading pluginの行とLSP notification handlers registered successfully for all N server(s)の行の順序を見ます。プラグインの読み込みより先にサーバー登録が完了し、Nが0のまま止まっていれば、issue #14803と同種の競合状態が再発している可能性があります。その場合はissue #14803へのリンク付きで新しいバグ報告を出すのが確実です。
まとめ
「No LSP server available」は、$PATH未設定のような単純な設定ミス以外に、ワークスペースの未信頼・拡張子の競合・バージョン依存の設定スキップ・LSPマネージャーの競合状態という4種類の原因を持ちます。拡張子の競合はv2.1.205より前だと初期化に失敗したサーバーが拡張子を塞いだまま残ることもあり、issue #14803で報告された競合状態はv2.1.0とv2.1.76の2段階の修正で解消されています。まずclaude --versionでバージョンを確認するのが最短の切り分けです。それでも解消しない場合は、claude --debugのログでプラグイン読み込みとサーバー登録の順序を確認します。