Claude Code LSPの使い方：プラグイン導入と動かないときの対処

2026年11月2日時点のClaude Code（2.1.316）でLSPを使う方法は、環境変数を設定することではなく、二つのものを入れることです。一つは自分のマシンに入れる言語サーバー（TypeScriptならnpm install -g typescript-language-server typescript）、もう一つはClaude Codeにその言語サーバーの起動方法を伝える公式の「コード インテリジェンス プラグイン」で、ターミナルのClaude Codeで/plugin install typescript-lsp@claude-plugins-officialと入力して入れます。PythonやGo、Java、C#なら、pyright-lspやgopls-lspのように言語ごとのプラグイン名に置き換えます。古い記事にあるENABLE_LSP_TOOLは不要です。

入れたあとにClaudeが得るものは二つあります。ファイルを編集するたびに自動で届く型エラーなどの診断と、定義や参照をたどるLSPツールです。診断は何もしなくても届きますが、LSPツールはClaudeが呼ぶかどうかを自分で判断します。動いているかは、Claudeにわざと型エラーを入れさせ、会話にFound 1 new diagnostic issue in 1 file (ctrl+o to expand)のような行が出るかで確かめます。

インストールがPlugin "typescript-lsp" not found in marketplace "claude-plugins-official"で失敗したときは、先に/plugin marketplace add anthropics/claude-plugins-officialで公式マーケットプレイスを登録します。クラウドセッションでは言語サーバーが起動しないため、この機能自体が使えません。入れたのに何も変わらない場合は、言語サーバーがPATHにない、プロジェクトに必要なパッケージがないなど原因がいくつかあり、症状ごとに後半の対応表で切り分けられます。

LSPは言語サーバーとプラグインの組み合わせ：Claudeが得る2つの情報

Claude CodeのLSP対応で一番混同されやすいのは、言語サーバーとプラグインが別物だという点です。言語サーバーはtypescript-language-serverやpyright-langserver、goplsのような独立したプログラムで、エディターの補完やエラー表示を支えているものと同じです。コード インテリジェンス プラグインは、どのコマンドで言語サーバーを起動し、どの拡張子のファイルを任せるかをClaude Codeに伝える設定にすぎず、Claude Codeの公式ドキュメント「コード インテリジェンス プラグイン」にも、プラグインに言語サーバーは含まれないと書かれています。プラグインだけを入れても、言語サーバーが手元になければ何も起きません。

言語サーバーが動いていると、Claudeは二種類の情報を受け取ります。一つ目はClaudeがファイルを編集または作成するたびに届く診断で、自分が入れてしまった型エラー、足りないimport、構文エラーを、コンパイラを走らせずに知ることができます。二つ目はLSPツールで、テキスト検索の代わりにシンボル単位で定義へのジャンプ、参照の一覧、型情報の表示、呼び出し階層の追跡ができます。公式のツールリファレンスのLSPツールの説明によると、このツールは読み取り専用で、実行時に権限の確認は出ません。

LSPとMCPはどちらもClaude Codeに機能を足す仕組みですが、LSPは言語サーバー専用の接続で、外部サービスやデータにつなぐのはMCPの役割です。MCPから何を入れるか迷っている場合はClaude CodeのおすすめMCP：最初に入れる一つを作業別に選ぶを参照してください。

導入手順：言語サーバー → プラグイン → 診断行で確認

導入は「言語サーバーを入れる、プラグインを入れる、サーバーが起動したかを確かめる」の順で進めます。順番を逆にしても壊れはしませんが、言語サーバーがない状態でプラグインだけ入れると、Claudeの会話には何のエラーも出ないため、原因が分かりにくくなります。Claude Code本体がまだなら、先にClaude Codeのインストール方法と始め方：セットアップと最初の起動で起動まで済ませてください。

1. 次の節の対応表で自分の言語の行を探し、言語サーバーをインストールします。TypeScriptとJavaScriptならnpm install -g typescript-language-server typescriptです。

2. claudeを起動するのと同じシェルで、言語サーバーがPATH上にあるかを確かめます。macOSやLinuxならwhich typescript-language-server、PowerShellならGet-Command typescript-language-serverで、パスが表示されれば問題ありません。

3. ターミナルでclaudeを起動し、プロンプトで次のように入力します。typescript-lspの部分は自分の言語のプラグイン名に置き換えます。

   コピー

   /plugin install typescript-lsp@claude-plugins-official

4. すぐには入らず、/plugin画面でそのプラグインの詳細が開きます。自分だけで使うならInstall for you（ユーザースコープ）を選びます。リポジトリの共同作業者にも有効にしたいならInstall for all collaborators on this repository（共同作業者はそれぞれ言語サーバーを入れ、claude plugin install typescript-lsp@claude-plugins-official --scope projectを一度実行する必要があります）、このリポジトリで自分だけならInstall for you, in this repo onlyです。完了後にRun /reload-plugins to apply.と出ても、LSPツールが増える再読み込みはそのままでは実行されず、This reload adds the LSP toolという警告とともに/reload-plugins --forceを求められます。新しいセッションを始めるか、/reload-plugins --forceを実行します。

5. Claudeに「このファイルにわざと型エラーを入れてから直して」と頼み、会話にFound 1 new diagnostic issue in 1 file (ctrl+o to expand)のような行が出れば、言語サーバーは起動しています。行が出なければ、/pluginを開いてErrorsタブを確認します。

言語サーバーは、Claudeがそのプラグインの拡張子のファイルを初めて扱ったときに起動します。VS Code拡張機能やデスクトップアプリから入れる場合は、手順3の代わりにそれぞれのプラグイン画面を使います（/plugin installの画面の見方はClaude CodeのおすすめSkills：用途別の選び方と公式スキルの導入手順でも扱っています）。--forceを付けて再読み込みすると、次のメッセージで会話全体をキャッシュなしで読み直すことになるため、長い会話の途中なら新しいセッションのほうが無難です。その理由はClaude Code のキャッシュミスと token コスト：1 回の turn が急に高く見える理由で説明しています。

言語別のプラグインと言語サーバー：13言語の対応表

2026年11月2日時点で公式マーケットプレイスにあるコード インテリジェンス プラグインは13言語分です。Liquid用のliquid-lspはShopifyが保守し、それ以外はAnthropicが保守しています。インストールコマンドは、公式マーケットプレイス（2026年10月30日のコミット）にある各プラグインのREADMEに書かれているものです。

プラグインを入れるときは、どの言語でも/plugin install プラグイン名@claude-plugins-officialの形です。JavaとKotlinは起動に時間がかかるため、マーケットプレイスの設定で起動待ちの上限（startupTimeout）が120,000ミリ秒に延ばされています。表にない言語は、後半の.lsp.jsonの節の手順で自分で追加できます。

ENABLE_LSP_TOOLはもう不要：2.1.316ではどちら向きにも効かない

settings.jsonのenvに"ENABLE_LSP_TOOL": "1"を書く手順は、LSPツールが入ったばかりのころの名残です。Claude Codeの変更履歴によると、LSPツールは2025年12月19日の2.0.74で追加されました。現在のツールリファレンスは、言語のコード インテリジェンス プラグインを入れるまでこのツールは無効のままだと説明しており、Claude Codeの環境変数リファレンスにもこの変数は載っていません。一方で、karanbansal.inのClaude Code LSPの解説記事（2026年2月28日）は、GitHub issue #15619発の非公式な回避策として今もこのフラグを書き込むよう案内しています。Scott Spenceは2026年10月10日の「Revisiting LSP in Claude Code」で、フラグを外しても2.1.296でLSPが読み込まれると報告しています。

2026年11月2日にmacOSのClaude Code 2.1.316で、普段とは別の設定ディレクトリを使い、ローカルのモック APIにつないで（実際のモデルは呼ばずに）TypeScriptの3ファイルのプロジェクトで確かめたところ、このフラグはどちら向きにも効きませんでした。プラグインを入れた状態でENABLE_LSP_TOOL=0にしてもLSPツールは提供され、診断も届きました。逆にプラグインを無効にしてENABLE_LSP_TOOL=1にすると、LSPツールは出ず、デバッグログにはTotal LSP servers loaded: 0と出ました。LSPを有効にするのはプラグインで、フラグを書いても書かなくても結果は変わりません。以下の確認結果も、特に断りがない限りこの環境でのものです。

not found in marketplaceエラー：公式マーケットプレイスを登録する

インストールでPlugin "typescript-lsp" not found in marketplace "claude-plugins-official"やMarketplace "claude-plugins-official" not foundが出るのは、公式マーケットプレイスがまだ登録されていないときです。Claude Codeのプラグインのトラブルシューティングによると、公式マーケットプレイスは対話型のターミナルセッションを初めて起動したときに自動で登録されます。そのため、VS Code拡張機能しか使ったことがない場合、ポリシーでそのソースが禁止されている場合、CLAUDE_CODE_DISABLE_OFFICIAL_MARKETPLACE_AUTOINSTALLを設定している場合、前回の登録に失敗して再試行待ちの場合は登録されていません。シェルから実行するclaude pluginコマンドは、登録を代わりにしてくれません。

2026年11月2日に、一度も対話型セッションを起動していない新しい設定でシェルからclaude plugin install typescript-lsp@claude-plugins-officialを実行すると、このエラーに加えてYour local copy may be out of date — try claude plugin marketplace update claude-plugins-officialと表示されました。ところが、勧められたとおりclaude plugin marketplace update claude-plugins-officialを実行してもMarketplace 'claude-plugins-official' not found. Available marketplaces: anthropic-plugin-directoryで失敗し、登録済みはanthropic-plugin-directoryだけでした。効いたのはマーケットプレイスの追加です。

/plugin marketplace add anthropics/claude-plugins-official

シェルからならclaude plugin marketplace add anthropics/claude-plugins-officialです。Successfully added marketplace: claude-plugins-officialと出たあとにインストールをやり直すと、typescript-lsp@claude-plugins-official (scope: user)として入り、claude plugin listではバージョン1.0.0、有効の状態になりました。エラー文が勧めるmarketplace updateは、マーケットプレイスが登録済みで中身が古いときの対処で、未登録のときには使えません。

Claudeが受け取る診断とLSPツール：会話の表示で動作を確かめる

診断は、Claudeが編集したその場のツール結果には入っていませんでした。モック APIに送られてきたリクエストを保存して確かめると、.tsファイルを書いた直後のツール結果にはファイル作成の成功だけがあり、診断は次のターンに別のシステムメッセージとして届いていました。モデルが受け取った原文は次のとおりです。

<new-diagnostics>The following new diagnostic issues were detected:

checkout.ts:
  ✘ [Line 3:43] Argument of type 'string' is not assignable to parameter of type 'number'. [2345] (typescript)</new-diagnostics>

このときの言語サーバーは、初期化に69ミリ秒、ファイルを開いてから診断を返すまで約0.58秒でした（3ファイルの小さなプロジェクトでの値です）。Claudeが型エラーを直したあと、言語サーバーは0件の診断を返し、Claude Codeは空の診断を送りませんでした。「直った」というメッセージは届きません。ただし、診断が届かないからといって、編集にエラーがないとは限りません。Scott Spenceの報告では、編集が最後の操作だった短いセッションでは型エラーが報告されないまま終わり、長いセッションでは約30秒後に届いた例もありました。また、Bashでシェルから変更したファイル（git checkoutやフォーマッターによる変更も含む）は言語サーバーに伝わらないことがあるとしています。

ターミナルの画面では、Found 1 new diagnostic issue in 1 file (ctrl+o to expand)の行がWriteの行の下ではなく、その次のツールの行（「Ran 1 shell command」）の下に出ました。公式ドキュメントは「エラーを入れた編集の下に出る」と説明していますが、診断が非同期で届くため、一行遅れて表示されることがあります。問題の中身を読むにはCtrl+Oを押します。

LSPツールのほうは、最初からツール一覧に並んでいるわけではありません。.tsファイルを初めて書いた（または読んだ）あと、Claude Codeは「ToolSearchで使えるツール」としてLSPを知らせるだけで、ツールの詳しい定義はClaudeがToolSearchで呼び出したときに初めて送られます。使える操作はgoToDefinition、findReferences、hover、documentSymbol、workspaceSymbol、goToImplementation、prepareCallHierarchy、incomingCalls、outgoingCallsの9つで、行と列は1始まりで指定します。サーバーが準備できたあとの結果は次のとおりでした。

LSPを入れたのに動かない：症状から原因と対処を引く表

LSPが動かないとき、Claude自身はたいてい何も教えてくれません。2026年11月2日の確認では、言語サーバーがPATHにない場合も、プロジェクトにtypescriptパッケージがない場合も、モデルには「LSPツールが使える」という知らせだけが届き、診断もエラー文も届きませんでした。原因はClaude Codeの/plugin画面のErrorsタブか、claude --debugで起動したときのデバッグログで探します。Claude Codeの環境変数リファレンスによると、デバッグログは既定で~/.claude/debug/にセッションID名の.txtファイルとして保存され、保存先はCLAUDE_CODE_DEBUG_LOGS_DIR（名前と違い、ディレクトリではなくファイルのパスを指定）で変えられます。

server is startingの全文は、2026年11月2日の実行で出たError performing goToDefinition: Failed to sync file open …: Cannot send notification to LSP server 'plugin:typescript-lsp:typescript': server is startingです。このときのモック APIは数ミリ秒で次の操作を返し、実際のモデルよりはるかに速かったため、最初の編集の直後に呼んだgoToDefinition、findReferences、hover、workspaceSymbolがすべてこのエラーになりましたが、4秒待ったあとは正しく返りました。実際のモデルがここまで早く呼ぶことはまれですが、起動途中の時間帯があることは覚えておく価値があります。

プラグインの設定そのものが壊れていてClaude Codeの起動に影響していると疑うときは、claude --safe-mode（またはCLAUDE_CODE_SAFE_MODE=1）で起動すると、言語サーバーを含むプラグイン類を読み込まずに始められます。クラウドとローカルの実行の違いはClaude Code に Web 版はあるのか：クラウド実行、Remote Control、Desktop を分けて考えるで整理しています。

初回のfindReferencesが1件だけ：useSyntaxServerで回避する

TypeScriptでは、セッションで最初に呼んだfindReferencesが、参照の一覧ではなく定義そのもの1件だけを返すことがあります。Scott Spenceの「Revisiting LSP in Claude Code」（2026年10月10日、Claude Code 2.1.296、SvelteKitのリポジトリ）では、新しいセッションの最初の呼び出しが19セッション中18回、さらに時間を計った13セッションではすべてFound 1 referenceになり、2回目以降は正しい結果になりました。プロジェクトの読み込みが終わる前に問い合わせが届き、typescript-language-serverが軽量の構文サーバーで先に答えてしまうのが原因で、Pythonの言語サーバーでも「最初は1件、そのあと全部」という同じ報告があるとしています。彼によると、Claude CodeのGitHubにはこの問題を追うissueが開いています。

2026年11月2日に、Claudeにsrc/price.tsを読ませてから同じ関数のfindReferencesを1ターンに1回ずつ3回呼ばせると、公式のtypescript-lspでは3セッションとも最初の呼び出しがFound 1 reference: src/price.ts:1:17でした。正解は3ファイルにまたがる5件で、2回目と3回目も「1、5、5」「1、1、1」「1、1、5」とばらつきました。回避策は、言語サーバーの設定に次のinitializationOptionsを加えることです。

{
  "typescript": {
    "command": "typescript-language-server",
    "args": ["--stdio"],
    "extensionToLanguage": { ".ts": "typescript", ".tsx": "typescriptreact", ".js": "javascript", ".jsx": "javascriptreact", ".mts": "typescript", ".cts": "typescript", ".mjs": "javascript", ".cjs": "javascript" },
    "initializationOptions": { "tsserver": { "useSyntaxServer": "never" } }
  }
}

この設定を入れる方法は二つあります。一つは、公式プラグインの設定が入っている~/.claude/plugins/marketplaces/claude-plugins-official/.claude-plugin/marketplace.jsonを開き、lspServersのtypescriptにinitializationOptionsを足す方法ですが、マーケットプレイスの更新で上書きされる可能性があります。もう一つは、上の内容を.lsp.jsonにした別のローカルプラグインを作り、公式のtypescript-lspを/plugin disable typescript-lsp@claude-plugins-officialで無効にする方法で、Scott Spenceはこちらを自分のマーケットプレイスで配布しています。

2026年11月2日には後者の形で、上の.lsp.jsonを持つローカルプラグインをclaude --plugin-dirで読み込み、公式プラグインを無効にして同じ手順を2セッション試し、どちらも「5、5、5」と最初から正しい結果になりました。Scott Spenceの測定でも12セッションすべてで最初の呼び出しが正しくなり、メモリ使用量も減った一方、最初の呼び出しは読み込みを待つぶん遅くなりました（彼のプロジェクトで約2秒）。大きなリポジトリでは待ち時間がさらに延びると考えておき、Claude Code側で修正されたら公式プラグインに戻します。

LSP plugin recommendationダイアログ：4つの選択肢と戻し方

"LSP plugin recommendation"（公式日本語ドキュメントでは「LSP プラグイン推奨」）ダイアログは、言語サーバーはPATHにあるのに、それを使うプラグインが入っていないときに出ます。条件は、Claudeがファイルを編集したこと、追加済みのマーケットプレイスか公式マーケットプレイスにその拡張子のプラグインがあること、そのプラグインの言語サーバーが入っていることです。複数のマーケットプレイスに候補があれば公式が優先され、表示は1セッションに最大1回で、クラウドセッションでは出ません。2026年11月2日に、プラグインをアンインストールしてtypescript-language-serverをPATHに置いた状態でClaudeに.tsファイルを書かせると、ターンの直後にこのダイアログが出ました。プラグインを入れたまま無効にした状態では出ませんでした。

迷ったら、その言語でLSPを使いたいなら「Yes, install」、いまは要らないなら「No, not now」で十分です。30秒間どれも選ばないと無視したものとして数えられ、無視が5回たまると「Disable all LSP recommendations」を選んだのと同じ状態になります。提案を元に戻すには、Claude Code自身の設定ファイル~/.claude.jsonからlspRecommendationDisabledとlspRecommendationIgnoredCountのキーを消します。「Never for this plugin」を取り消すときは、同じファイルのlspRecommendationNeverPluginsのリストからtypescript-lsp@claude-plugins-officialのような該当IDを消します。

.lsp.jsonで公式プラグインのない言語を追加する

対応表にない言語でも、言語サーバーさえあれば、.lsp.jsonを持つ小さなプラグインを作ってつなげます。注意したいのは、2026年11月2日の確認でclaude plugin validateが.lsp.jsonの中身を見ていなかったことです。YAML用の設定で、知らないキーextensionsを使ったもの、commandに空白を入れたもの、拡張子のキーに点を付け忘れたものの3つの壊れた版を作っても、正しい版と同じく「Validation passed with warnings」で通りました。誤りが分かるのは読み込んだときだけです。

1. プラグイン用のフォルダを作り、.claude-plugin/plugin.jsonに名前を書きます。例は{ "name": "yaml-lsp-local", "version": "0.1.0", "description": "yaml-language-server for .yaml/.yml" }です。

2. 同じフォルダの直下に.lsp.jsonを置き、起動コマンドと拡張子を書きます。

   jsonコピー

   {
     "yaml": {
       "command": "yaml-language-server",
       "args": ["--stdio"],
       "extensionToLanguage": { ".yaml": "yaml", ".yml": "yaml" }
     }
   }

3. claude --debug --plugin-dir ./yaml-lsp-localのように、--plugin-dirでそのセッションだけプラグインを読み込みます。ずっと使うならマーケットプレイスに置きます。

4. デバッグログにLoaded 1 LSP server(s) from plugin: yaml-lsp-localと出れば設定は読み込まれています。LSP config validation failed for .lsp.json in plugin yaml-lsp-localとUnrecognized key: "extensions"のような行が出たら、その言語サーバーは読み込まれていません。

5. YAMLのファイルをClaudeに編集させ、診断行が出るかを確かめます。言語サーバー本体（この例ではyaml-language-server）は別にインストールしておきます。

Claude Codeのプラグインリファレンスによると、必須はcommandとextensionToLanguageの二つです。commandには引数を含めず（/で始まる絶対パス以外は空白不可）、引数はargsに書きます。extensionToLanguageのキーは".go"のように点から始めます。任意の項目にはenv、initializationOptions、settings、workspaceFolder、startupTimeout、shutdownTimeout、requestTimeout（既定60,000ミリ秒、v2.1.288以降）、restartOnCrash、maxRestarts、diagnosticsなどがあり、リストにないキーがあると設定全体が検証に失敗します。第三者が配っているLSPプラグイン集を入れる前に中身を確かめる方法は、Claude Code modsとは：導入手順と、validateだけでは見えない権限で扱っています。

言語サーバーのメモリ使用量：重いときはプラグインを止める

言語サーバーはプロジェクトを索引する間メモリを使い、公式のトラブルシューティングは特にrust-analyzerとpyrightがプロジェクト全体を索引すると説明しています。開発マシンが重くなるなら、そのセッションで/plugin disable pyright-lsp@claude-plugins-officialのようにプラグインを無効にし、Claudeの組み込みの検索に任せるのが公式の案内です。止めても失うのは編集後の診断とシンボル検索だけで、Claudeはこれまでどおりgrepなどでコードを探します。

どのくらい使うかは言語とプロジェクトの大きさ次第です。目安として、Scott SpenceのSvelteKitプロジェクトではtypescript-language-serverが約935MB（4プロセス）を使い、findReferencesの節のuseSyntaxServer: "never"を入れると約725MB（3プロセス）でした。LinuxとWSLでCLAUDE_CODE_TOOL_MEMORY_LIMITによってツールのメモリに上限をかけている場合、言語サーバーもその上限の対象に数えられることがあり、v2.1.246以降はCLAUDE_CODE_TOOL_MEMORY_CGROUP_EXCLUDE=lspで外せます。

VS CodeでClaude Codeを使っていてもプラグインは必要か

VS Code拡張機能経由でClaude Codeを使っていても、編集のたびに自動で届く診断とLSPツールが欲しいなら、プラグインと言語サーバーは必要です。Claude CodeのVS Code向けドキュメントによると、VS Codeと連携したClaude Codeはmcp__ide__getDiagnostics（チャットパネルではv2.1.285以降mcp__claude-vscode__getDiagnostics）でVS Codeの「問題」パネルのエラーや警告を読めます。ただしこれはエディターの言語サーバーの結果を、Claudeが必要なときに読みに行く別の仕組みで、プラグインの診断のように編集後に自動で届くものでも、定義や参照をたどるLSPツールでもありません。VS Code拡張機能では、プラグインはターミナルの/plugin installではなく拡張機能のプラグイン画面から入れます。

LSPを入れてもClaudeがgrepを使うとき：CLAUDE.mdにルールを書く

LSPツールが使えるようになっても、Claudeがそれを使うとは限りません。Scott Spenceの2026年10月10日の検証では、CLAUDE.mdに「シンボルを探すときはLSPを使う」という明示的なルールを書くと、シンボルについての質問12回すべてでLSPが使われましたが、ルールを外すと使われたのは約半分で、リファクタリングでは3回中0回でした。一方、彼の実際の履歴では、LSPを入れた2月末から4月までの約650セッションのうち、LSPが呼ばれたのは15セッション、合計32回だけでした。

ただし、LSPを使えば常に良くなるわけではありません。Scott Spenceが「grepのみ」「LSPとgrep」「LSPのみ」を各3回、計54セッションで比べた結果では、grepの答えは正しく、findReferencesはコードではなくファイル・行・列だけを返すため、LSPのみの実行では参照1件ごとに3〜6ファイルを読んでいました。vi.mockの文字列での参照や、.tsから.svelteへの呼び出し元はLSPでは見つからず、LSPが優れていたのはhoverによる型の確認でした。彼はCLAUDE.mdを「定義や使用箇所はgrepで探す」「正確な型が必要なときはLSPのhover」「findReferencesを完全な一覧とみなさない」「診断は編集の後のターンに届くので、完了を報告する前に型チェックを実行する」という内容に書き直しています。LSPをどの場面で使わせるかは、このようにCLAUDE.mdやスキルにルールとして書くのが確実です。ルールをどこに置くかはClaude CodeのHooks・Skills・スラッシュコマンドを使い分ける：呼び出し方と設定例を参考にしてください。

Claude Code LSPのよくある質問

claude -pのスクリプト実行でもLSPは使われますか？

--bareを付けなければ使えます。2026年11月2日時点のClaude Codeのドキュメントでは、スクリプト向けのclaude -pに--bareを付けるとLSPサーバーを起動しないとされています。Scott Spenceもclaude -pのヘッドレス実行でLSPツールが呼ばれることを確かめており、CIなどで診断を使いたいなら--bareを外します。

WindowsでもClaude CodeのLSPは使えますか？

使えます。Claude Codeの変更履歴によると、Windowsでファイルのパスが正しく渡らずLSPが動かない問題は2026年3月12日の2.1.74で修正されています。言語サーバーがPATHにあるかは、PowerShellのGet-Command typescript-language-serverのように確かめ、C/C++ならwinget install LLVM.LLVMのようにREADMEのWindows向けコマンドで入れます。

LSPツールにもReadの拒否ルールは効きますか？

効きます。LSPツールは読み取り専用で権限の確認なしに動きますが、Read(~/secrets/**)のようなReadのパスのルールはLSPツールにも適用されるとClaude Codeのツールリファレンスに書かれています（2026年11月2日時点）。秘密ファイルを置いた場所は、Readの拒否ルールで指定しておけばLSPツールからも対象外になります。