Claude Codeの権限確認で迷ったとき:許可・拒否・一度だけ許可の判断表
AIを使いこなすClaudeで執筆し、GPTで自動校閲・修正しています。

結論から言うと、迷ったときは「中身を読んで判断する」より先に「操作の種類」で線を引くと決めやすくなります。目安は次の4つです。 • 読み取り:作業フォルダ内のソースなら基本は許可。秘密ファイルは除く • 編集:依頼の範囲内で差分を後で確認できるなら許可。確認できないなら、許可する前に対象と変更内容を説明してもらう • コマンド実行:1回ごとに中身を読む。恒久的な許可は、範囲の狭いものに限る • 削除・強制上書き・外部送信・本番操作:許可しない。自分で実行する 確認が毎回出ると、読まずに押す癖がつきます。そこで、先に線を決めておき、確認が出たらその表に当てはめます。 なお、公式ドキュメントでは、バージョン2.1.283以降の対話型ターミナルとVS Codeは、条件が合えば auto モードで始まると説明されています(Permission modes、2026-10-29に公式本文を確認)。auto モードでは別の分類モデルが確認を肩代わりします。この記事の表は、確認を自分で見る Manual モード(default)を前提にしています。auto でも、自分が書いた ask/deny ルールは有効です。
まず知っておく:確認が出る場面
Manual モードで確認が出るかどうかは、操作の種類で決まります(Configure permissions)。
- ファイル読み取り・Grep、確認:作業ディレクトリ内は不要、「Yes, and don't ask again」の効く範囲:なし
- ファイル編集・書き込み、確認:必要、「Yes, and don't ask again」の効く範囲:セッション終了まで
- Bashコマンド、確認:必要(組み込みの読み取り専用コマンドを除く)、「Yes, and don't ask again」の効く範囲:リポジトリとコマンドごとに恒久的
- WebFetch、確認:必要(事前承認された文書ドメインを除く)、「Yes, and don't ask again」の効く範囲:リポジトリとドメインごとに恒久的
- WebSearch、確認:必要、「Yes, and don't ask again」の効く範囲:リポジトリごとに恒久的
ここで大事なのは、編集の許可はセッションで切れるのに、コマンドの許可は残る点です。コマンドの「今後も許可」は保存されます。CLIでは通常、Gitリポジトリのルートにある .claude/settings.local.json に allow ルールとして書かれます。Gitリポジトリ外やWindowsなどでは保存先が異なる場合があります(Configure permissions)。読み取り専用コマンドには ls、cat、git status などが含まれ、確認なしで動きます(Security)。
許可判断表
下の「判断」は公式の仕様ではなく、この記事の提案です。
- 読み取り、具体例:作業フォルダ内のソースを読む、判断:許可、理由・確認すること:副作用がない
- 読み取り、具体例:作業フォルダ外、.env、鍵、認証情報、判断:拒否または一度だけ、理由・確認すること:秘密を会話に取り込むため。必要なら説明用のダミー値に置き換える
- 編集、具体例:依頼した機能のファイル、判断:許可(git diff で後から確認できるとき)、理由・確認すること:差分を確認できる。既存の未コミット変更は先に退避する
- 編集、具体例:依頼と関係ないファイル、設定ファイル、CI定義、判断:先に理由と差分を確認し、必要なら一度だけ、理由・確認すること:依頼の範囲外
- 編集、具体例:.git、.claude、シェルの設定ファイルなど、判断:一度だけ。原則断る、理由・確認すること:公式でも保護対象に挙がっている
- コマンド、具体例:テスト、lint、ビルド、判断:実行内容を確認したものだけ、範囲の狭い恒久許可でもよい、理由・確認すること:同じ名前でもスクリプトや依存の変更で動作が変わるため、変更時は見直す
- コマンド、具体例:パッケージのインストール、判断:一度だけ、理由・確認すること:依存の追加は、レビュー対象に加える
- コマンド、具体例:削除、強制push、reset --hard、判断:拒否。自分で実行、理由・確認すること:取り返しがつきにくい
- コマンド、具体例:外部への通信、スクリプトの実行、判断:送信先・内容・副作用を先に確認。外部送信や破壊的操作は拒否し、それ以外は必要なら一度だけ、理由・確認すること:次章
- Web取得、具体例:公式ドキュメントのURL、判断:ドメイン単位で許可してよい、理由・確認すること:知らないドメインは一度だけ
注意すべきコマンド例
以下は説明用の例です。実際に実行して確かめた結果ではありません。
- rm -rf build/、何が起きるか:指定フォルダを再帰的に削除する、判断:拒否。生成物のフォルダか確認して自分で実行する
- git push --force、何が起きるか:リモートの履歴を上書きする、判断:拒否
- git reset --hard、何が起きるか:未コミットの変更を捨てる、判断:拒否。先に自分で退避する
- curl https://example.com/install.sh \、何が起きるか:bash、判断:取得したスクリプトをそのまま実行する、拒否。ダウンロードして中身を読んでから、自分で判断する
- curl -X POST -d @data.json https://…、何が起きるか:ファイルの内容を外部へ送る、判断:送信先と送る内容が分かるまで許可しない
- npm install <パッケージ名>、何が起きるか:依存と実行スクリプトが増える、判断:一度だけ。名前の綴りとlockファイルの差分を確認
- sed -i 's/…/…/' 多数のファイル、何が起きるか:複数ファイルを一括で書き換える、判断:対象を絞れているか確認。実行後に差分を見る
- sudo …、chmod -R …、何が起きるか:sudo は別ユーザー(通常は管理者)の権限で実行し、chmod -R はアクセス権を再帰的に変える、判断:拒否
- terraform destroy、本番DBの移行、何が起きるか:本番の資源やデータを変える、判断:拒否。人が手順書に沿って実行
公式側にも裏付けのある点を挙げます。
- Manual モードでは、curl と wget は既定では自動承認されません。明示的な allow ルールがあれば確認を省略できます(Security)。
- auto モードでは、curl | bash 型の実行、強制push、git reset --hard、terraform destroy、本番デプロイなどは、分類モデルが既定でブロックする対象です。ただし、明示的な許可ルールや会話中の具体的な承認で実行可能になる場合があります(Permission modes)。
- rm の対象がファイルシステムのルート、ホーム、作業ディレクトリ本体やその親などの重要パスと認識された場合は、通常は確認または拒否になります。ただし、bypassPermissions でこの確認を無効にする設定もあるため、常に止まるとは限りません(同ページ)。
ただし、これらは「公式が止める場合がある」という話です。止められなかったときに最後に判断するのは自分です。
「Yes, and don't ask again」を押す前の3問
- 来週も、この形のまま実行されて困らないか。 コマンドの恒久許可は保存されます。npm run test のような固定の形でも、実行するスクリプトや依存の内容を確認し、変更時は許可を見直します。
- 許可の範囲が、必要以上に広くないか。 Bash(git *) のような広いルールは、git push --force まで含みかねません。
- 実行結果を、後から見て確認できるか。 編集は git diff で見られます。外部送信やデータ削除は、後からは見られません。
恒久許可の範囲だけが心配で、その操作自体は安全と判断できるなら「一度だけ」を選びます。操作自体が不明・危険なら拒否します。間違えて恒久許可したルールは、/permissions で見直せます(Configure permissions)。
線を設定に書く
毎回の判断を減らすには、決まった線を設定ファイルに書きます。公式の設定ページには、lintとテストを許可し、.env の読み取りを拒否する例があります。~/.claude/settings.json に、この形で書きます(Settings)。
{
"permissions": {
"allow": [
"Bash(npm run lint)",
"Bash(npm run test *)"
],
"deny": [
"Read(./.env)",
"Read(./.env.*)"
]
}
}ネットワークコマンドを止めたい場合は、permissions.deny に Bash(curl *) のようなルールを足します。ただし deny ルールは、コマンドが書かれた形で照合されます。別の書き方をされると素通りする場合があります。通信そのものを制限したいなら、サンドボックスのネットワーク分離を使うよう公式が案内しています(Security)。
もう1点あります。Read の deny ルールは、cat などClaude Codeが認識するBashのファイル操作にも適用されます。ただし、ファイル名を指定しない再帰検索や、Python・Nodeのスクリプトが間接的に読む場合などには適用されません。すべてのプロセスからのアクセスを制限したい場合は、サンドボックスのファイルシステム制限を使います(Configure permissions)。
設定ファイルが読み込まれたかは /status、権限ルールの一覧は /permissions で確認できます(Configure permissions)。編集した設定は、多くの場合そのままセッションに反映されます(Settings)。
依頼文で範囲を伝える
許可の判断を減らすには、依頼の段階で範囲を決めておきます。以下は、そのまま使える説明用の依頼文です。
このリポジトリのテストを実行して、失敗しているものを直してください。
- 変更してよいのは src/ と tests/ の中だけです
- 依存パッケージの追加、git push、ファイルの削除は、実行前に私に確認してください
- .env など認証情報のファイルは読まないでください
- 変更が終わったら、変更したファイルと理由を一覧で報告してくださいauto モードでは、会話の中で「pushしないで」と伝えると、一致する操作が止まります。ただしこの指示は権限ルールとして保存されず、コンテキストの圧縮で失われる場合があります(Permission modes)。長い作業で守らせたい線は、依頼文だけでなく、前章の deny ルールにも書いておきましょう。
確認の画面が出たら、自分で見るのは3点です。何を(コマンドの全文)、どこを(対象のパスや送信先)、戻せるか(削除や送信でないか)。この3点で判断がつかないなら、許可せず、Claude に目的と影響範囲を説明させます。

