Claude CodeがWSLで重い・権限プロンプトが消えない——症状別に公式ドキュメントとGitHub Issueで原因を特定した
Claude CodeをWSL2で使うと応答開始まで1〜6分かかる、起動直後にフリーズする、settings.jsonの許可設定が効かない——症状別にGitHub Issueと公式ドキュメントの一次情報で原因を切り分け、対処法とネイティブWindows/WSLの選び方をまとめた。
エンジニアのゆとです。
Claude CodeをWSL2にインストールして、いざ使い始めたら「hello」と打つだけで応答が始まるまで数分かかる——という報告が、2026年に入ってからGitHub Issueにずっと積み上がっている。インストール自体は成功しているし、エラーメッセージも出ない。ただ、遅い。それも「気のせい」で片付けられるレベルではなく、1〜6分待たされるレベルで。
「claude code wsl どっち（ネイティブかWSLか）」で検索した人に向けて、今回はインストール手順の話ではなく、セットアップが終わった後に実際に踏む詰まりポイントを症状別に整理した。応答の異常な遅さ、起動直後のフリーズ、settings.jsonの許可設定が効かない問題——それぞれ別のGitHub Issueとして報告されていて、原因も対処の方向性もまったく違う。公式ドキュメントとGitHub Issueの一次情報をもとに、何が原因で、今どこまで直せて、どこは回避策しかないのかをまとめる。
インストール手順そのものは別記事で扱っているので、まだWSL2にClaude Codeを入れていない場合はそちらを先に読んでほしい。
まず整理する — 「WSLで動かす」には2つの意味がある
本題に入る前に、混同しやすい前提を1つ潰しておく。「Claude CodeをWSLで使う」という言い方には、実は2つの別物が含まれている。
1つ目は、WSLのターミナルを開いて、そこで直接 claude コマンドを実行するやり方。CLIそのものがWSLディストリビューション内にインストールされていて、Linuxのプロセスとして動く。今回扱うトラブルの大半はこちらに関するものだ。
2つ目は、Claude Code Desktopアプリの「Code」タブが、WSL 2ディストリビューション内でセッションを実行する機能。Desktopアプリ自体はWindows上で動きつつ、セッションの中身（プロセス・ツール・git）はWSL側のLinux環境で処理される。
公式ドキュメントには、この2つ目のDesktopアプリ経由のWSLセッションについて、まだ使えない機能がはっきり明記されている。
要件としては「WSL 2であること（WSL 1は非対応）」「ディストリビューション内に git が入っていること」の2点。組織管理下のデバイスでは、WSLセッション自体が管理者の判断で無効化されている場合もある。「WSLセッションが選べない・起動できない」という場合、まずここを疑うといい。
以降で扱う症状1〜4は、基本的に1つ目のCLI直接実行のケースを対象にしている。Desktopアプリ側の話は都度明記する。
症状1: プロンプトを送っても応答が始まるまで1〜6分かかる
これが今回いちばん厄介な症状だ。「hello」のような一言でも、思考フェーズ（応答が出力され始める前の待ち時間）だけで1〜6分かかる。トークンのストリーミング自体は始まってしまえば普通の速度で、遅いのは「始まるまで」の部分だけ、という特徴がある。
GitHub Issueを追うと、2026年1月末ごろから同種の報告が積み上がっていて、バージョンが進むごとに悪化していったことがわかる。
もう1つ興味深いのが、この遅延は「プロジェクトを /mnt/c/ ではなくWSLネイティブの /home/ 配下に置く」という、よくある高速化の定石を守っていても発生するという点だ。
つまりこの遅延は、ファイルI/Oの話ではなく、WSL2環境そのものとClaude Codeの特定バージョンの組み合わせで起きる回帰（リグレッション）バグだ。3件ともAnthropic側からの直接の返信はなく「not planned」でクローズされている。2026年8月時点で、公式からの恒久的な修正は確認できていない。
対処法 — 現状は「ダウングレードして様子を見る」が唯一の実践的な手段
原因側の修正がまだない以上、できることは限られる。
- まず自分の症状が本当にこれに該当するか確認する。ネイティブLinux環境や、Windows側で
claude doctorを実行して、同じアカウント・同じモデルで速度差があるかを見る - 該当するなら、いったん安定していたバージョンにダウングレードする
# 特定バージョンを指定してインストール（WSL内で実行）
curl -fsSL https://claude.ai/install.sh | bash -s 2.1.17
# 現在のバージョンを確認
claude --versionminimumVersionを設定していると意図せず新しいバージョンに戻されることがあるので、settings.jsonで自動更新のチャンネルも合わせて確認しておく
{
"autoUpdatesChannel": "stable",
"minimumVersion": "2.1.17"
}"stable" チャンネルは、大きな回帰があったリリースをスキップする代わりに最新版より1週間ほど遅れる。最新機能を追いかけるより「動くこと」を優先するなら、WSL2ではこちらに寄せておいたほうが精神衛生上いい。
症状2: 起動直後にフリーズする・入力がガクつく
こちらは症状1とは別の話で、コマンド実行前のハングや、文字を打つたびにワンテンポ遅れる「スタッター」として報告されている。
原因として有力なのが、WSL側からWindowsの環境変数を都度取得する処理でPowerShellの呼び出しが挟まり、そのたびに待ち時間が発生しているというもの。Claude Codeコミュニティの検証記事に、具体的な回避策が載っている。
対処法として紹介されているのが、~/.bashrc（または ~/.zshrc）に1行追加して、WindowsのUSERPROFILEパスを起動時に一度だけ解決しておくというものだ。
# ~/.bashrc または ~/.zshrc に追記
export USERPROFILE=$(wslpath -u $(pwsh.exe -NoLogo -NoProfile -Command 'Write-Output ${env:USERPROFILE}'))追記後は設定を読み込み直す。
source ~/.bashrc念のため書いておくと、これはAnthropic公式の対処法ではなく、コミュニティが検証した回避策だ。効くかどうかは環境によって差があるので、まず自分の .bashrc のバックアップを取ってから試すのが安全。動作が変わらない・むしろ悪化した場合はすぐに戻せるようにしておく。
症状3: WSLのターミナルで実行しているのに、Windows側のバイナリが動いている
これは気づきにくい割に影響が大きい症状だ。WSLのネイティブターミナル（Ubuntu等）から claude を実行しているつもりが、実際にはGit Bash（MINGW64）経由でWindows側のバイナリが呼ばれてしまうケースが報告されている。
症状としては、作業ディレクトリが \\wsl.localhost\Ubuntu\home\... のようなUNCパス形式で表示される、git コマンドが「dubious ownership」エラーを出す、WSL内でインストールしたツール（php・docker・composerなど）にPATHが通っていない、といった形で現れる。ファイル監視まわりでは、こんなエラーも報告されている。
Error: EISDIR: illegal operation on a directory,
watch '//wsl.localhost/Ubuntu/home/<user>/repo/.claude'確認方法
自分の環境がこれに該当するか、まず簡単なコマンドで切り分けられる。
# WSLのターミナルで実行して確認する
uname -a
# Linux ... と出ればWSLネイティブ、MINGW64_NT... と出ればWindows側が動いている
which claude
# パスがWSL内(/home/... や /usr/local/bin/claude)を指しているか確認uname -a の結果がLinuxカーネルではなくMINGW64を返す場合、原因はClaude Code側のインストールの問題というより、WindowsとWSL両方にGit BashとWSL版のClaude Codeが混在していて、PATHの解決順序でWindows側が先に見つかっているケースが多い。この手のPATH競合・複数インストールの切り分け方は、別記事でOS横断で整理しているので、詳しく潰したい場合はそちらを参照してほしい。
このIssueはAnthropic側で「not planned」としてクローズされているため、根本修正を待つより、WSL内で改めて公式インストーラーを実行し直し、.bashrc や .profile でWindows側のパスをWSLのPATHより先に読み込んでいないか確認するのが現実的な対処になる。
症状4: settings.jsonの許可設定(allowlist)が効かず、毎回プロンプトが出る
.claude/settings.local.json にglobパターンで許可を書いても、WSL環境だと無視されて毎回「Yes, allow」を選び直す羽目になる、という報告もある。
Desktopアプリ経由でWSLプロジェクトを開いた場合も、別の切り口で同様の問題が報告されている。
この2件も「not planned」でクローズ済みで、globパターンのマッチャーがWSL/Windowsのパス形式との組み合わせでうまく動いていない可能性が高いと推測されている（Issue内のコメントでの推測であり、Anthropicによる原因の確定情報ではない）。
対処法と注意点
Issue内で紹介されている回避策は --dangerously-skip-permissions フラグだが、これは名前の通り「危険」なオプションだ。
claude --model sonnet --dangerously-skip-permissionsこのフラグを使うと、破壊的なコマンドも含めてすべての確認プロンプトがスキップされる。Issue報告者自身も「Git管理下にあるコード、かつ単一開発者の環境限定で推奨」と注釈をつけている。チーム開発や、機密情報を扱うプロジェクトでは避けたほうがいい。
許可設定そのものの基本的な考え方（allowlistの設計・スコープの使い分け）は別記事でまとめている。WSL特有の不具合を踏まえた上で、それでも安全に運用したい場合の設計の参考にしてほしい。
現実的な落としどころとしては、--dangerously-skip-permissions を常用するのではなく、作業内容を絞った短いセッション単位でだけ使う、あるいは信頼できるコマンドだけを Bash() パターンで許可する（こちらは動作報告があるパターン）に寄せる、といった運用でリスクを下げるのが現実的だ。
症状5: /mnt/c/ 配下のプロジェクトを開くと重い・ファイル監視が壊れる
これは他の症状と違って、Anthropic公式ドキュメントに明記されている「仕様」だ。
つまり C:\Users\...\project を /mnt/c/Users/.../project としてWSLからマウントして開く構成そのものが、遅さとファイル監視の不安定さの原因になる。これは症状1（バージョン起因の回帰）とは別問題で、こちらはプロジェクトの置き場所を変えるだけで解決する。
対処は明確で、プロジェクトをWSLのネイティブファイルシステム（~/projects/ など）に置き直すこと。この構成でのセットアップ手順・Windows側からのアクセス方法は別記事に詳しく書いてあるので、まだ /mnt/c/ 配下で運用している場合はそちらを参照して移行してほしい。
Native Windows・WSL2・WSL1、結局どれを選ぶべきか
ここまで読んで「じゃあWSLはやめてネイティブWindowsにすべきでは」と思った人もいるはずだ。公式ドキュメントの比較表を見ると、判断材料はシンプルに整理されている。
| 選択肢 | 必要な準備 | サンドボックス | 向いている用途 |
|---|---|---|---|
| Native Windows | 不要（Git for Windowsは任意） | 非対応 | Windowsネイティブなプロジェクト・ツール |
| WSL 2 | WSL 2の有効化 | 対応 | Linuxツールチェーン、サンドボックス実行が必要な場合 |
| WSL 1 | WSL 1の有効化 | 非対応 | WSL 2が使えない環境の代替 |
サンドボックス機能（コマンド実行を隔離環境で行う機能）が必要かどうかが、実質的な分岐点だ。今回扱ったような遅延・フリーズ・許可設定の不具合は、現状すべてWSL2側で報告されているものであり、ネイティブWindowsであればそもそも遭遇しない症状も含まれる。
とはいえ、Linuxツールチェーンに依存するプロジェクト（Dockerを多用する、本番がLinuxサーバー、等）では、ネイティブWindowsに逃げると別の非互換性に直面する。「WSLのバグを避けるためにネイティブに戻す」と「本番環境に近いLinux環境で開発する」のどちらを優先するかは、プロジェクトの性質次第で答えが変わる。
恒久対策・チェックリスト
その場しのぎだけでなく、詰まった時に順番に確認できるチェックリストとしてまとめておく。
- まず
claude doctorでインストール状態と設定ファイルの妥当性を確認する - 応答が異常に遅い場合、ネイティブLinuxや別環境と速度を比較し、症状1に該当するか切り分ける。該当するなら
autoUpdatesChannel: "stable"への切り替えとダウングレードを検討する - 起動時のフリーズ・入力のスタッターがあれば、USERPROFILE解決の回避策を試す前に、まず
.bashrcのバックアップを取っておく uname -aでWSLネイティブとして動いているか確認する。MINGW64が返る場合はPATHの競合を疑う- 許可プロンプトが毎回出る場合、
--dangerously-skip-permissionsは用途を限定してから使う - プロジェクトが
/mnt/c/配下にある場合は、WSLネイティブファイルシステムへの移行を検討する
# 診断コマンドをまとめて実行する
claude --version
claude doctor
uname -a
which claudeFAQ
WSL1でも動く？
動くが、公式には非推奨で、サンドボックス機能も使えない。過去には Exec format error が出て起動できないケースも報告されていた。WSL1を使っている場合は、可能な限りWSL2への移行を検討したほうがいい。
wsl --set-version Ubuntu 2結局、WSL2でClaude Codeを使うのはやめたほうがいい？
そこまでは言えない。今回扱った遅延・フリーズ系のバグは深刻だが、症状1・症状2に該当しない環境では快適に動いている報告も多い。まず自分の症状がどのパターンに当てはまるかを切り分けてから判断するのが遠回りに見えて早い。Linux依存のプロジェクトであれば、多少の不具合を抱えてでもWSL2を使う価値はある。
Desktopアプリ経由のWSLセッションでできないことは?
公式ドキュメントには、統合ターミナル・コネクタとプラグイン・セッションのフォーク・ファイルブラウザペイン・コンポーザーでの @ によるファイルサジェストの5つが、まだWSLセッションでは使えないと明記されている。これらの機能が必要な場合は、WSLのターミナルから直接CLIを起動する構成のほうが今のところ機能が揃っている。
claude doctor の結果はどう読めばいい?
インストール状態・設定ファイルの妥当性・直近の自動更新結果を、セッションを開始せずに確認できる診断コマンドだ。読み取り専用なので、症状の原因を疑うたびにとりあえず実行して損はない。警告が出た場合は、そこに書かれている修正案から順に試すのが最短ルートになる。
まとめ
Claude CodeのWSL関連トラブルは、1つの原因にまとめられるものではなく、バージョン起因の応答遅延・環境変数解決によるフリーズ・PATH競合によるWindows側バイナリの誤実行・許可設定のバグ・ファイルシステム配置の問題と、性質の異なる複数の不具合が別々に報告されている状態だ。
「WSLで重い」と感じたら、まず claude doctor と uname -a で状態を確認し、症状1〜5のどれに近いかを切り分ける。バージョン起因のものはダウングレードと stable チャンネルへの切り替えが現状の最善策で、ファイル配置起因のものは /home/ 配下への移動で確実に直る。この2つを混同したまま対処すると、直る問題も直らなくなる。
