Claude Codeの"permission denied"を症状別に切り分ける——EACCESとAuto Modeクラシファイアは別物だった
Claude Codeでpermission deniedが出る原因は一つじゃない。npm installのEACCES権限エラーと、2026年8月にAuto Modeが標準になったことで急増した「classifierによる拒否」を、公式ドキュメントとGitHub Issueの一次情報で切り分けて整理した。
エンジニアのゆとです。
Claude Codeで「permission denied」と出て詰まった人向けの記事を書こうとGitHub Issueを漁っていたら、想定してたのと違う話に行き着いた。
「npm installでEACCESが出る」系の古典的な権限エラーは、実は解決策がほぼ固まっている。ネイティブインストーラーに切り替えれば大体片付く。厄介なのはそっちじゃなくて、2026年8月14日以降、Pro/Max/Teamプランで新規セッションの標準モードが「Auto Mode」に切り替わったことで急増している、まったく別種の「permission denied」だ。
「Permission for this action was denied by the Claude Code auto mode classifier」——これはOSの権限エラーじゃない。allowlistに入れてても、bypassPermissionsを指定してても拒否される、という報告がここ2週間のGitHub Issueに次々積み上がっている。
この記事では、この2種類の「permission denied」を症状別に切り分けて、それぞれの原因と対処法を公式ドキュメントとGitHub Issueの一次情報でまとめた。どっちに当てはまるか分からないまま片方の対処法を試して「直らない」と困っている人向けの内容になっている。
まず切り分ける — 「permission denied」には性質の違う2種類がある
結論から言うと、Claude Codeで見る「permission denied」は大きく2パターンに分かれる。
| パターン | 発生タイミング | エラーの正体 | 発生時期 |
|---|---|---|---|
| A. OSレベルの権限エラー | インストール時・ファイル作成時 | OS(npm/ファイルシステム)がアクセスを拒否 | 以前からある古典的な問題 |
| B. Auto Modeクラシファイアの拒否 | セッション実行中 | AIによる安全性審査が「危険」と判定 | 2026年8月のAuto Mode標準化以降に急増 |
パターンAは、Claude Code自体の不具合というよりOSの一般的な権限管理の話で、npmのグローバルインストール先が自分の所有じゃない、ファイルの実行ビットが立っていない、といった原因がはっきりしている。
パターンBは事情が違う。Claude Codeが「これは危険な操作かもしれない」と判断したときに、AIの分類器(classifier)が実行前に止める仕組みで、2026年3月にリリースされた機能自体は新しくない。ただし2026年8月14日、Claude Code 2.1.228以降でPro/Max/Teamプランの新規セッションのデフォルト起動モードがAuto Modeに変わったことで、今まで一度もこの機能を意識してこなかった人が急にこの拒否に遭遇するようになった。
まずこの2つを混同しないことが最短ルートになる。順番に見ていく。
パターンA — OSレベルの権限エラー(EACCES系)
npm install で EACCES: permission denied が出る
いちばん典型的なのがこれだ。npm install -g @anthropic-ai/claude-code を実行すると、こういうエラーで止まる。
npm error code EACCES
npm error syscall access
npm error path /usr/local/lib/node_modules
npm error errno -13
npm error Error: EACCES: permission denied, access '/usr/local/lib/node_modules'原因は明確で、npmのグローバルインストール先ディレクトリがroot所有になっているのに、rootではない自分のユーザーで書き込もうとしているから起きる。Anthropic公式のトラブルシューティング記事にも、この原因がそのまま書かれている。
ここで絶対にやってはいけないのが sudo npm install -g で押し通すことだ。一時的には通っても、root所有のファイルができてしまい、次のアップデートやアンインストールで別の権限エラーを踏むことになる。公式ドキュメントも「sudoは使うな」と明言している。
対処法1(推奨) — ネイティブインストーラーに切り替える
npmを経由せず、Node.js不要でインストールできるネイティブインストーラーに乗り換えるのが、公式が案内している本命の対処法だ。
# macOS / Linux
curl -fsSL https://claude.ai/install.sh | bash
# Windows PowerShell
irm https://claude.ai/install.ps1 | iexこのインストーラーは自前のランタイムを内包していて、npmのグローバルディレクトリの権限問題を丸ごと回避できる。バックグラウンドで自動更新もしてくれるので、以降のバージョンアップ時にまた同じエラーを踏む心配もない。
対処法2 — npmのままいく場合はprefixを変更する
どうしてもnpm経由を維持したい事情がある場合は、グローバルインストール先を自分のユーザーが所有するディレクトリに変更する。
npm config set prefix ~/.npm-global変更後、~/.npm-global/bin をPATHに追加するのを忘れずに。
# ~/.bashrc または ~/.zshrc に追記
export PATH=~/.npm-global/bin:$PATH追記後は source ~/.bashrc(または ~/.zshrc)で反映させてから再度インストールする。
zsh: permission denied: claude や command not found になる場合
インストール自体は成功しているのに、実行しようとすると「permission denied」または「command not found」が交互に出るケースもある。これは実行ビットが落ちている、もしくはPATHの解決順序でWindows側やGit Bash側のバイナリが先に見つかっているパターンで、原因の切り分け方は別記事にまとめてある。
ファイル作成・編集時に EACCES: permission denied が出る
インストールは無事終わったのに、Claude Codeがファイルを作成しようとした瞬間に権限エラーで止まる、という報告もGitHub Issueに上がっている。
このケースは作業ディレクトリの所有権や、親ディレクトリのパーミッション設定を疑うのが定石になる。まず自分のユーザーがそのディレクトリに書き込み権限を持っているか確認する。
# 現在のディレクトリの所有権とパーミッションを確認
ls -la .
# 自分のユーザーに所有権を戻す(macOS/Linux)
sudo chown -R $(whoami) .chown のときだけはsudoを使ってよい。ここでのsudoは「自分のホームディレクトリ配下の所有権を自分に戻す」操作であって、npmのグローバルディレクトリに書き込む操作とは別物だからだ。
パターンB — Auto Modeクラシファイアによる”permission denied”
ここからが今回いちばん書きたかった話だ。パターンAの対処法をひと通り試しても直らない「permission denied」がある場合、疑うべきはOSの権限ではなくAuto Modeのクラシファイアになる。
そもそもAuto Modeとは何か
Auto Modeは、ファイル編集やコマンド実行のたびに人間に確認を求める代わりに、専用の分類器モデル(classifier)がその場で安全性を判断して実行の可否を決める仕組みだ。仕組みの詳細は別記事で扱っているので、まだ触れたことがない場合は先にそちらを読んでおくと理解が早い。
問題は、2026年8月14日以降、Claude Code 2.1.228(Windowsネイティブは2.1.233)以降のバージョンで、Pro/Max/Teamプランの新規セッションがデフォルトでこのAuto Modeから起動するようになったことだ。Manualモードで確認プロンプトを見ながら作業してきた人が、アップデートを機に何も知らないままAuto Modeに切り替わっている、というケースが相当数あると見ている。
公式ドキュメントは、初回だけ通知を出すとしている。
起動時のパーミッションモードがはじめてAuto Modeになったセッションでは、ターミナルの場合はセッション冒頭に一度だけ、このドキュメントへのリンク付きで通知を表示する
とはいえ流し読みしていれば見落としても不思議はない。「なんか最近、聞かれずに色々やってくれるな」くらいの感覚で使い続けて、ある日いきなり拒否に当たって困惑する、という流れが今のGitHub Issueの傾向に近い。
症状 — Permission for this action was denied by the Claude Code auto mode classifier
拒否されたときに表示される典型的な文言がこれだ。
Permission for this action was denied by the Claude Code auto mode classifier.
Reason: Blocked by classifier.Blocked by classifier というそっけない理由だけが表示され、具体的に何が引っかかったのかは書かれないことが多い(Claude Code 2.1.208以降の仕様)。ここがパターンAとの決定的な違いで、OSの権限エラーならエラーメッセージにパスやerrnoが出るが、こちらは「AIが危ないと判断した」という抽象的な理由しか出てこない。
公式ドキュメントには、拒否される代表的な操作の一覧がある。ここに該当していないのに拒否される場合は、次に紹介する「誤検知」の可能性が高い。
allowlistに入れているのに拒否される(誤検知パターン)
ここが今、GitHub Issueで最も報告数が多いパターンだ。permissions.allow に明示的にツール名を書いてあるのに、Auto Modeのクラシファイアがそれを無視して拒否する。
公式ドキュメントを読むと、これは仕様上の想定順序と矛盾している。本来の評価順序は「1. allow/ask/denyルールで即座に解決 → 2. 作業ディレクトリ内の読み取り専用操作・ファイル編集は自動承認 → 3. それ以外はclassifierへ」となっていて、allowlistに一致した時点でclassifierには回らないはずになっている。この矛盾自体がバグとして報告され続けている状態だ。
bypassPermissionsを指定しているのに拒否される
--dangerously-skip-permissions や permissions.defaultMode: "bypassPermissions" を設定しているセッションでも、Auto Modeのclassifierに引っかかるケースが報告されている。
公式ドキュメントの原則では、bypassPermissionsモードでも例外的に確認を求められるケースは「明示的なaskルール」「criticalパスへのrm/rmdir」など、ごく限られたリストに列挙されているだけで、Auto Modeのclassifierはそこに含まれていない。つまりこの動作自体が仕様と食い違っている、という位置づけで報告されている。
MCP経由の操作で「再認証しても直らない」
Google Driveなど外部サービスと連携するMCPコネクタでも、似た症状の報告がある。
これはAuto Modeのclassifier起因というより、MCPコネクタ側のスコープ設定とツール呼び出しの間で権限情報が正しく引き継がれていない可能性が高い。「reasonが曖昧なpermission denied」というくくりでまとめて調べていると混ざりやすいので、MCP連携の場合は再認証で直らない時点でMCPサーバー側のログも確認したほうがいい。
対処法 — 拒否されたときにできること
Auto Modeのclassifierによる拒否は、OSの権限エラーと違って「設定を1つ直せば終わり」という単純な話にならない。公式ドキュメントが案内している現実的な対処は次の3つだ。
1. /permissions の「Recently denied」タブから再試行する
拒否された操作は通知として表示され、/permissions コマンドの「Recently denied」タブに一覧される。ここで r キーを押すと、その操作だけ手動承認に切り替えて再実行できる。
# セッション内で実行
/permissions2. 3回連続または累計20回拒否されると自動でプロンプトに切り替わる
これは覚えておくと安心材料になる仕様で、同じ種類の拒否が3回連続、またはセッション内で累計20回発生すると、Auto Modeは一時停止して通常の確認プロンプトに戻る。この閾値は設定で変更できない。
3. 誤検知が多い場合は /feedback で報告するか、信頼できるインフラを管理者が設定する
公式ドキュメントは「繰り返し拒否される場合、大抵はclassifierが自分のインフラ構成を認識できていないことが原因」としている。個人利用の場合は /feedback で誤検知を報告する、チーム利用の場合は管理者が信頼できるリポジトリ・バケット・サービスを autoMode.environment 設定に登録する、という2つの経路が案内されている。
4. どうしても急ぎたい場合は、その場だけManualモードに戻す
Shift+Tab で auto から default(Manual)に切り替えられる。恒常的にAuto Modeを避けたい場合は、~/.claude/settings.json の permissions.defaultMode を明示的に "default" にしておけば、次回以降のセッションもManualから起動するようになる。
{
"permissions": {
"defaultMode": "default"
}
}ここで1つ注意点がある。この defaultMode の設定はプロジェクト側の .claude/settings.json や .claude/settings.local.json に書いても効かない。"auto" を有効にできるのはユーザー設定(~/.claude/settings.json)またはmanaged settingsだけで、プロジェクト側の設定は無視される仕様になっている。逆に言うと、Auto Modeをオフにして "default" に固定したい場合はこの制約を受けないので、チームの .claude/settings.json にManual固定を書いても機能する。
allowlistの設計自体を見直したい場合は、パーミッション設定の基本設計を扱った別記事も参考にしてほしい。Auto Modeの不具合を踏まえた上で、それでも確認頻度を抑えたい場合の設計パターンがまとまっている。
自分の症状がどっちのパターンか、コマンドで確認する
エラーメッセージだけで判断がつかない場合、以下の手順で切り分けられる。
# 1. インストール状態と設定ファイルの妥当性を確認
claude doctor
# 2. 現在のバージョンを確認(2.1.228未満ならAuto Modeはそもそも標準化されていない)
claude --version
# 3. 現在のパーミッションモードを確認(ステータスバー表示)
# ⏵⏵ auto mode on / ⏸ manual mode on などの表示を見るエラーメッセージに EACCES、errno、具体的なファイルパスが含まれていればパターンA(OSレベル)。Blocked by classifier や auto mode classifier という文言が含まれていればパターンB(Auto Mode)、という判断基準になる。ステータスバーに auto mode on と出ている状態で原因不明の拒否に遭遇したら、まずパターンBを疑うのが早い。
OS別の追加の注意点
WindowsやWSL環境では、パターンA・Bどちらとも別に、環境固有の権限まわりの不具合がいくつか報告されている。WSL特有の症状(許可設定が無視される、settings.jsonのglobパターンが効かない等)は別記事で詳しく扱っているので、WSL環境で本記事の対処法を試しても改善しない場合はそちらも確認してほしい。
macOSの場合、Gatekeeperやシステム整合性保護(SIP)が絡んで実行がブロックされるケースもある。ネイティブインストーラーで入れ直すことで大半は解消するが、それでも直らない場合はターミナルアプリ自体にフルディスクアクセス権限が付与されているかを「システム設定 → プライバシーとセキュリティ」から確認するといい。
恒久チェックリスト
詰まった時に上から順に試せるチェックリストとしてまとめておく。
claude doctorでインストール状態と設定ファイルの妥当性を確認する- エラーメッセージに
EACCESやファイルパスが含まれるか確認する。含まれていればパターンA - パターンAなら、npm経由をやめてネイティブインストーラーに切り替える。sudoは使わない
- ファイル作成時のEACCESなら、作業ディレクトリの所有権を
chown -R $(whoami) .で確認・修正する - エラーに
Blocked by classifierやauto modeが含まれるか確認する。含まれていればパターンB - パターンBなら
/permissionsの「Recently denied」からrで再試行する - 誤検知が多発する場合、個人なら
/feedback、チームなら管理者にautoMode.environmentの設定を依頼する - とにかく急ぎたいときは
Shift+TabでManualモードに一時的に戻す。恒久的に避けたいなら~/.claude/settings.jsonのdefaultModeを"default"に固定する(プロジェクト側の設定では無効なので注意)
# 診断コマンドをまとめて実行する
claude --version
claude doctorFAQ
Auto Modeを完全に無効化することはできる?
個人アカウントでは、~/.claude/settings.json の permissions.defaultMode を "default" に設定すれば、新規セッションはManualモードから起動する。組織管理下の場合は、管理者がmanaged settingsで permissions.disableAutoMode を "disable" に設定すると、Auto Mode自体がShift+Tabのサイクルからも消える。
Blocked by classifier としか表示されないのはなぜ?
Claude Code 2.1.208以降、多くのセッションでは拒否理由が固定文言の Blocked by classifier になっていて、詳しい説明は表示されない仕様になっている。理由を深掘りしたい場合は /permissions の「Recently denied」タブから該当の拒否を確認するのが現状の手段になる。
sudo npm install -gで一度は成功したが、今度は別のエラーが出るようになった
典型的な「rootで書き込んだファイルが後から邪魔をする」パターンだ。一度sudoでインストールした環境は、中途半端にroot所有のファイルが残っている可能性が高い。この場合は既存のグローバルインストールを削除してから、ネイティブインストーラーで入れ直すのが確実になる。
# 既存のnpmグローバルインストールを削除(該当する場合)
npm uninstall -g @anthropic-ai/claude-code
# ネイティブインストーラーで入れ直す
curl -fsSL https://claude.ai/install.sh | bashAuto Modeの拒否は、セキュリティ的には信頼していい?
「安全側に倒した結果として誤検知が多い」というのが現状に近い。ドキュメント自身も「Auto Modeはプロンプトを減らすが安全性を保証するものではない」と明記している。誤検知の多さにストレスを感じる場合、無理にAuto Modeを使い続けるより、Manualモード+Bashサンドボックスのauto-allowモードを組み合わせる方が、確認頻度を抑えつつ挙動が予測しやすいこともある。
まとめ
Claude Codeの「permission denied」は、原因の階層が全く違う2種類が同じエラー文言でくくられている状態だ。npm installやファイル作成時に出るならOSの権限エラーで、ネイティブインストーラーへの切り替えや所有権の修正で大体片付く。一方、セッション実行中に理由もなく拒否される、allowlistに入れているのに効かない、という場合は2026年8月にPro/Max/Teamの標準モードになったAuto Modeのclassifierを疑うべきで、こちらは設定ファイルの修正だけでは直らないことも多い。
「permission denied」という文字列だけで検索して、片方の対処法を全部試しても直らない、という人は、まずステータスバーで今どのモードにいるかを確認するところから始めるのが遠回りに見えて早い。
