Claude CodeがWSLでEACCESになり起動しない原因と対処
WSLで /mnt/c/Program Files/ClaudeCodeのEACCESによりClaude Codeが起動しない問題の原因を解説します。Windows側の管理設定を探す処理と、バージョン別の挙動、回避策をまとめます。
起動できない原因は /mnt/cの管理設定探し
WSL上のClaude Codeが EACCES: permission denied, scandir '/mnt/c/Program Files/ClaudeCode/managed-settings.d' で止まるのは、起動時にWindows側の管理設定の置き場を調べに行き、その読み取りがOSに拒否されたときです。管理設定ファイルが壊れているわけではなく、Windows側に管理設定を配っていなくても起きます。
条件は2つそろったときです。
/mnt/cへのアクセスをWSLユーザーに許可していない(automountの制限、専用アカウントでの実行など)- 使っているClaude Codeのバージョンが、拒否された読み取りを致命的なエラーとして扱う
先に結論を書くと、バージョンを上げることが第一の対処です。拒否された読み取りで落ちる挙動は、v2.1.285で変わったことがエラー解説に書かれています。以降の節で、症状の見分け方、バージョンごとの違い、更新できないときの手段を順に見ます。
症状の見分け方
報告されている症状は2通りあります。
| 表示 | 出方 | 報告 |
|---|---|---|
EACCES: permission denied, scandir '…/managed-settings.d' | 出方起動時 | 報告#101013 |
Unable to read managed policy settings. と Detail: /mnt/c/Program Files/ClaudeCode/managed-settings.json: Settings file could not be read: EACCES … | 出方セッション開始時(claude --version は通る) | 報告#91816 |
どちらも対象パスは /mnt/c/Program Files/ClaudeCode/ 配下です。WSLから見えるWindowsのCドライブ上で、Windows版の管理設定が置かれる場所にあたります。
#101013の報告者は、セキュリティ上の理由でコーディング用アカウントから /mnt/c へのアクセスを無効にしていたと書いています。バージョンは具体的な番号がなく、「最新」とだけ記されています。#91816の報告では、/mnt/c/Program Files の時点で EACCES になっており、探している ClaudeCode ディレクトリのひとつ上で拒否されています。
WSLのClaude CodeがWindows側を覗く理由
管理設定は、WSLでは通常 /etc/claude-code/managed-settings.json を読みます。ただし wslInheritsWindowsSettings を true にすると、WSLがWindows側のポリシーも読みます。このキーが効くのはHKLMレジストリか、C:\Program Files\ClaudeCode\ 配下のファイルに書いたときだけです。どちらもWindowsの管理者権限がないと書けません。仕組みの詳細はwslInheritsWindowsSettingsの仕組みと設定方法にまとめています。
つまりWSL側は、このキーが立っているかどうかを知るために、/mnt/c/Program Files/ClaudeCode/ の managed-settings.json と managed-settings.d/ を先に調べる必要があります。#91816の報告者は、この確認が無条件に走るため、/mnt/c が読めない環境で ENOENT(存在しない)でなく EACCES(拒否)が返ると、そこで失敗すると分析しています。
managed-settings.d/ は managed-settings.json の隣に置ける任意のディレクトリで、チームごとの設定断片を分けて配るために使います。Windowsなら C:\Program Files\ClaudeCode\ にあたり、WSLからは /mnt/c/Program Files/ClaudeCode/managed-settings.d として見えます。
管理設定を配っていないのになぜ
- 後輩
Windows側に管理設定は置いていません。それでもWindowsのフォルダを見に行くんですか。
- 先輩
置いてあるかどうかは、見に行かないと分かりません。継承の旗はWindows側にしか置けないので、まず見る必要があります。
- 後輩
見えない場所は「無い」と同じ扱いにならないんですね。
- 先輩
存在しなければ問題なし、読めなければ要判断、という分かれ目があります。その判断がバージョンで変わりました。
バージョンで挙動が分かれる
エラー解説には、Unable to read managed policy settings の扱いが次のように書かれています。
- OSが読み取りを拒否した場合(root専用ファイルなど)は、そのソースのポリシーなしでセッションが始まる
- I/Oエラーのようにそれ以外の理由で読めない場合は、起動時に終了する
- v2.1.285より前は、OSが拒否した読み取りでもこのエラーで終了していた
この3点から、/mnt/c の権限拒否で落ちるのは「v2.1.285より前のバージョン」の症状と整理できます。#91816はv2.1.258では動き、v2.1.259で失敗するようになった回帰として報告されています。コメントには2.1.275でも発生したとの追記があります。
一方、#101013は2026年10月10日の報告で、バージョンの記載が「最新」としかありません。起票時点の最新版でも再現したのかどうかは、報告文から読み取れません。このissueには duplicate ラベルが付き、状態はopenです。
手元の状態を確かめるコマンド
まず、バージョンと /mnt/c の見え方を確認します。
claude --version
ls -ld /mnt/c "/mnt/c/Program Files"
mount | grep /mnt/cls が Permission denied を返すなら、Claude Codeの問題ではなくWSL側の権限で止まっています。claude --version が通るのにセッションだけ失敗するのは、#91816と同じ型です。
v2.1.285以降でも不安なときは、セッションに入れる状態で claude doctor を実行します。読めなかったソースは /status と claude doctor に記録されると、管理設定のドキュメントに書かれています。-p で実行したときは標準エラー出力にも出ます。
対処の選択肢
1. Claude Codeを更新する
v2.1.285以降ならOSに拒否された読み取りで終了しない、というのが文書上の挙動です。WSL内のインストール方法に合わせて更新します。
claude update
claude --version更新後も同じエラーが出る場合は、#101013に近い状況の可能性があります。バージョンと全文のエラーを添えて、そのissueか#91816に情報を足すのが近道です。
2. /mnt/c を読める状態に戻す
/mnt/c を意図して閉じているなら、閉じたまま使うのが目的です。閉じていないのに権限エラーが出ているなら、WSLのautomount設定や実行ユーザーの権限を見直します。/mnt/c を開けるとWindows側の全ファイルがWSLから見えるため、閉じている理由を先に確認します。
3. 報告者の回避策を使う(自己責任)
#101013のコメントには、/mnt/c の上に空のtmpfsを読み取り専用でかぶせてからClaude Codeを起動する回避策が書かれています。unshare でユーザーとマウントの名前空間を分け、その中でだけ /mnt/c を空にする方法です。
REAL="$HOME/.local/bin/claude"
exec unshare --user --map-current-user --mount --keep-caps \
sh -c 'mount -t tmpfs -o ro,size=0 none /mnt/c && exec "$0" "$@"' \
"$REAL" "$@"投稿者自身が「terrible but working(ひどいが動く)」と書いている手段です。/mnt/c の中が空に見えるため、そのセッションからWindows側のファイルは読めなくなります。ラッパーとして claude の代わりに呼ぶ形で、Claude Code本体は変更しません。
#91816のコメントには、Bunのpreloadでファイル読み取りの EACCES を ENOENT に読み替える回避スクリプトも投稿されています。2.1.277向けに書かれたもので、/mnt/c が読めない環境専用と注記されています。Windows側のポリシーが実在する環境で使うと、ポリシーを読まずに起動するため、管理者の意図を外すことになります。
管理者の立場で見るべきこと
読めないのに無視して進む、という挙動はセキュリティ上のトレードオフでもあります。管理設定のドキュメントには、HKLMの値、managed-settings.json、managed-settings.d/ のどれかが「存在するが読めない」場合、HKCUやWSLの /etc/claude-code よりも優先して扱う旨が書かれています。読めない管理文書を「無い」と見なすと、実在する統制が外れかねません。
そのためv2.1.285以降の挙動でも、OSの拒否だけは例外として「ポリシーなしで起動し、/status と claude doctor に記録する」扱いになっています。組織でWSLを統制している場合は、次の点を押さえます。
- Windows側に管理設定を配っている端末では、WSLユーザーが
/mnt/cを読める状態にする - 読めない設計にするなら、
wslInheritsWindowsSettingsを使わず、/etc/claude-codeに必要な設定を直接置く - 回避策で
/mnt/cを隠した端末は、Windows側のポリシーが適用されない前提で管理する
管理設定の全体像はClaude Code組織管理ガイドにあります。
同じ起点で起きる別の症状
/mnt/c/Program Files/ClaudeCode を起点にした問題は、起動エラーのほかにも報告があります。
- WSL2のsandbox初期化で、このパスのbind(マウント)に失敗し、サンドボックスなしで動いてしまう報告(#84563、open)。対処はWSL2 sandbox失敗の確認にまとめています
- 起動のたびに
reg.exeをWSLの相互運用(interop)経由で2回呼ぶ挙動(#100773、open)
#100773は、Claude Codeのプロセスが始まるたびに HKLM\SOFTWARE\Policies\ClaudeCode と HKCU\SOFTWARE\Policies\ClaudeCode の Settings 値を reg.exe query で読む、という報告です。約10セッションを動かして60秒間 ps を観察したところ、interopの reg.exe が10プロセス見えたと書かれています。Windowsがinteropの新しい通信路を割り当てられない障害の最中は、各呼び出しが約10秒待って失敗し、起動が遅れたとされています。報告者の提案は、WSLでは既定でスキップする、結果をキャッシュする、短いタイムアウトで起動を止めない、の3つです。
同じレジストリ照会でinteropが使えず起動時に落ちる別の問題は、#52318としてクローズ済みです。/mnt/c が読めない問題と reg.exe の問題は別の原因ですが、どちらもWSLがWindows側のポリシーを探す処理に根があります。
症状別の切り分け早見表
| 状況 | 疑う点 | 次の一手 |
|---|---|---|
scandir '/mnt/c/Program Files/ClaudeCode/managed-settings.d' でEACCES | 疑う点/mnt/c が読めない + 古いバージョン | 次の一手claude --version で2.1.285未満か確認し、更新 |
| 更新後も同じエラー | 疑う点#101013と同型の可能性 | 次の一手バージョンと全文を添えてissueに追記 |
Unable to read managed policy settings のみ | 疑う点読み取り失敗の理由がI/Oエラーなど | 次の一手Detail: の行が指すパスの状態を確認 |
| 起動は通るが遅い | 疑う点reg.exe のinterop照会(#100773) | 次の一手interopの状態を確認 |
| サンドボックスが効かない | 疑う点/mnt/c/Program Files/ClaudeCode のbind失敗(#84563) | 次の一手sandbox関連の記事を参照 |
初回のWSL2セットアップ全般はClaude Code WSL2セットアップが扱っています。
まとめ
/mnt/c へのアクセスを閉じたWSLでClaude Codeが EACCES で起動しないのは、Windows側の管理設定の置き場を調べる処理がOSに拒否されるためです。OSが拒否した読み取りでも終了するのはv2.1.285より前の挙動で、以降は「その場所のポリシーなしで起動し、/status と claude doctor に記録する」扱いに変わっています。
更新しても再現するときは、#101013に近い状況です。回避策のtmpfsやpreloadは、Windows側のポリシーを読まない前提で成り立つ手段なので、統制下の端末では使い道が限られます。