「No LSP server available」の原因と直し方 — Claude Code

Claude CodeのLSPツールを使おうとしてNo LSP server available for file type: .tsのようなエラーだけが返ってくることがあります。プラグインの設定は疑って当然です。ただし.lsp.jsonもプラグインの登録もenabledPluginsも正しいのに直らないケースが、実際に報告されています。本稿は、設定ミスの手前で疑う起動オプションと、issueトラッカーで報告された既知の競合状態を扱います。

「No LSP server available」が返る場面

LSPツールにdocumentSymbol・hover・findReferences・goToDefinitionといった操作を渡したとき、対象ファイルの拡張子を受け持つ言語サーバーが1つも動いていないと、このエラーが返ります。メッセージはファイル種別ごとに変わり、Pythonなら.py、TypeScriptなら.tsです。

エラー文は「言語サーバーが無い」という結果だけを伝えます。理由までは書かれていません。理由は大きく4種類に分かれ、症状ごとに見る場所が違います。

原因1: 起動オプションがLSPを止めている

claude --helpには、LSPを含む機能を丸ごと止めるオプションが2つあります。どちらも、普段使いのシェルエイリアスやCIのスクリプトに紛れ込んでいると気づきにくい種類の原因です。v2.1.289の出力は次のとおりです。

claude --help

  --bare                                Minimal mode: skip hooks (those defined
                                        in settings and by installed plugins;
                                        features built into Claude Code are
                                        unaffected), LSP, plugin sync,
                                        attribution, auto-memory, ...
  --safe-mode                           Start with all customizations
                                        (CLAUDE.md, skills, installed plugins,
                                        hooks, MCP servers, ...) disabled
                                        — useful for troubleshooting a broken
                                        configuration. ...
                                        Sets CLAUDE_CODE_SAFE_MODE=1.

--bareは-pを使うスクリプト向けの最小構成で、LSPとプラグイン同期を飛ばします。--safe-modeはインストール済みプラグインを含むカスタマイズを全部無効にします。環境変数ガイドによれば、CLAUDE_CODE_SAFE_MODE=1でも同じ状態になり、LSPサーバーも読み込まれません。

設定を何度見直しても直らず、エラーがすべての言語で出るなら、まず起動コマンドとenv | grep CLAUDE_CODEの出力を見ます。

原因2: .lsp.jsonの不備と言語サーバーの未検出

LSPプラグインが担うのは「どのコマンドでどの拡張子の言語サーバーを起動するか」の指定までです。言語サーバー本体は別にインストールします。この2点のどちらかが欠けると、サーバーは起動せずにエラーだけが残ります。失敗の理由は/plugin画面のErrorsタブに出ます。

• バイナリが見つからない: Executable not found in $PATH: "<binary>"という行が出ます。claude --debugのログにはLSP server <name> failed to start: <reason>と残ります
• .lsp.jsonの記述が不正: 1つでも不正なエントリがあるとファイル全体が読み込まれず、ErrorsタブにInvalid LSP server config for ".lsp.json"と出ます

言語サーバーは、プラグインが担当する拡張子のファイルをClaudeが初めて編集したときに起動します。起動できているかは、型エラーをわざと入れさせた編集の下にFound N new diagnostic issues in M filesという行が出るかで分かります。この行が出なければ、Errorsタブを開きます。

バイナリを入れ直したら、claudeを起動したシェルで$PATHが通っているかをwhichで確かめ、新しいセッションを始めます。$PATHはclaudeを起動したシェルのものが使われるため、別のディレクトリに入れた場合は、そのパスが通ったシェルから起動し直します。

2つ目は見落としやすい挙動です。claude plugin validateはこのファイルを検査しないため、検証が通っても読み込み時に落ちることがあります。plugin.jsonのlspServersに書く設定は、未知のキーが1つあるとプラグインごと読み込まれません。

$PATH未設定・メモリ消費・モノレポの誤検知は、Claude Codeのコードインテリジェンス(LSP)活用ガイドの「よくあるトラブルと対処」にまとめてあります。

なお、LSPツールの呼び出しがエラーを返さずに止まる場合は、別の症状です。サーバーが応答しないリクエストは、requestTimeoutの既定値である60秒で失敗します。この挙動はv2.1.288で入り、サーバーごとに.lsp.jsonで値を変えられます。

原因3: 同じ拡張子を複数のサーバーが宣言している

有効な2つのサーバーが同じ拡張子を宣言すると、先に登録された側がそのファイルを受け持ち、もう一方はその拡張子には使われません。サーバーが同じプラグインから来ても、別のプラグインから来ても同じです。ErrorsタブにはLSP server "<name>" is not used for <ext> filesという警告が出ます。

同じ名前のサーバーを宣言した場合は逆で、後から宣言した側が前の設定を置き換えます。「名前が同じなら後勝ち、拡張子だけ同じなら先勝ち」という違いが、原因の絞り込みに使えます。

たとえば自作のRust向けLSPプラグインと、公式マーケットプレイスのrust-analyzer-lspを両方有効にすると、.rsは先に登録された側だけが受け持ちます。拡張子の割り当てはClaude Codeプラグインに独自のLSPサーバーを組み込むの手順で見直せます。

v2.1.205より前には、先に登録されたサーバーが初期化に失敗すると、同じ拡張子を宣言する別プラグインの正常なサーバーまで使われない不具合がありました。このバージョンで修正されています。

原因4: LSPマネージャーとプラグイン読み込みの競合状態(issue #14803)

2025年12月20日、公式ドキュメントどおりに設定しても直らない報告が立ちました。.lsp.jsonもinstalled_plugins.jsonもenabledPluginsも正しく、言語サーバーのバイナリも$PATHから見えるのにNo LSP server availableが返り続けるという内容です。Python・TypeScript・Go・Swift・C・Elixir・C#(OmniSharp)と言語を問わず、コメントは70件を超えました。

コミュニティの調査では、npxで別バージョンを実行して比較しました。v2.0.67ではLSPマネージャーのgetAllLspServers()がプラグインの読み込みを待ち、3個のサーバーを登録しています。v2.0.76ではプラグインの読み込みが始まる1ミリ秒前に、マネージャーが「0個のサーバーで初期化完了」と記録していました。

# 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"

2025年12月23日の追跡コメントの投稿者は、v2.0.67から69以降の間にマネージャーの初期化が非同期化されたことが原因ではないかと推測していました。Anthropicのbcherny氏は2025年12月24日に「Fix incoming」とだけコメントしています。

issueの「Requested Fix」欄には、LSPサーバーの起動状況を一覧する/lspのようなステータスコマンドの要望もありました。現行の公式ドキュメントとchangelogに/lspコマンドの記載はありません。近い改善は、後述のv2.1.142で入りました。

症状が出るバージョンと修正の流れ

コミュニティの報告と公式changelogを突き合わせると、修正は1回では終わらず、プラグイン読み込みまわりのタイミング問題が段階的に直されたことが分かります。

v2.1.0の修正は、前節の競合状態と同じ症状を指します。一方、v2.1.76の修正は「マーケットプレイスの整合待ち」に起因する別のタイミング問題です。プラグインの読み込みとキャッシュの関係はClaude Codeプラグインのキャッシュとファイル解決の仕組みで扱っています。

issue #14803が荒れていた期間、コミュニティは公式の修正を待たずに、npxでv2.0.67を指定して実行する回避策や、初期化順序を書き換える非公式パッチを使っていました。いずれも公式の修正が入る前の一時しのぎで、Anthropicが検証したものではありません。v2.1.76以降が使えるなら、アップデートで足ります。

claude --version
npm install -g @anthropic-ai/claude-code@latest

切り分けの順番

アップデート後も直らない場合は、次の順で確かめます。

プラグインの読み込みより先にサーバー登録が完了し、Nが0のまま止まっているなら、issue #14803と同種の競合状態が再発している可能性があります。その場合は、issueへのリンクとデバッグログを付けて新しいバグ報告を出します。

まとめ

v2.1.76以降なら原因4は修正済みの範囲なので、残る原因1〜3は自分の設定で直せます。原因1〜3を外してもNが0のまま止まるなら、設定側ではなく競合状態の再発です。