3行でいうと

  • 許可の基準は「モード」で決まります。確認を毎回求める default（画面では Manual）、ファイル編集は自動で通す acceptEdits、計画だけ作る plan、別のAIが確認する auto、あらかじめ許可した以外は断る dontAsk、確認を全部飛ばす bypassPermissions の6つです。
  • Claude Codeのバージョンが v2.1.283 以降だと、対話型のターミナルでの標準の開始モードが auto になる、と公式に書かれています。「いつも確認される」と思い込んでいると、実際の動きと合わないかもしれません。
  • 「止めたいこと」は、CLAUDE.mdではなく、権限ルール（deny）に書きます。公式は、権限ルールはモデルではなくClaude Code本体が守らせるもの、と説明しています。

この記事は公式ドキュメントを2026年10月16日に読んでまとめたものです。この記事は、実際に使って確かめた記録ではありません。運営者はClaude Codeを入れていますが、使い心地はこの記事には書いていません。コマンドや設定のキーは、公式に書かれているとおりに写したもので動作確認はしていません。公式の文章は要約として取得したため、引用はせず言い換えています。セキュリティは助言ではなく、公式の記載の整理です。

先に結論

6つのモード

公式の表を整理します（確認日10月16日）。設定の値と、ターミナルでの旗は同じ名前です。

モード 聞かずに実行されること 公式が挙げる向き
default（画面では Manual） 読むだけ 一つ一つ自分で確かめたい作業、慎重に扱う作業
acceptEdits 読む、ファイル編集、mkdir、touch、mv、cp などの基本的なファイル操作 変更をあとでレビューしながら進めるとき
plan 読む（調べて、計画を書く。編集はしない）。autoモードが使える場合は、分類器が承認したコマンドも聞かずに実行されます 変更の前に、構成を調べるとき
auto ほぼ全部（裏で安全確認つき） 長い作業、確認の連続を減らしたいとき
dontAsk 読むことと、事前に許可済みのツールだけ。確認が必要になる操作は断る 自動化（CI）など、人が答えられない場面
bypassPermissions 全部 隔離したコンテナや仮想マシンの中だけ

manual という別名も使えます（v2.1.200以降）。たとえば claude --permission-mode manual です。

切り替え。 ターミナルでは Shift+Tab を押すたびに、default、acceptEdits、plan の順に回ります。auto は使える状況なら輪に入り、bypassPermissions は、そのモードを有効にして起動したときだけ輪に入ります。dontAsk は輪に入らず、--permission-mode dontAsk で指定します。/plan と打つと、プロンプトから直接、計画モードに入れます（説明を続けて書くと、その作業から始められる）。

開始モードは何で決まるか

公式の「Which mode a session starts in」によると、ターミナルで新しく始めるときは、次の順で最初に当てはまるものが使われます。

  1. --permission-mode の旗、または --dangerously-skip-permissions
  2. 設定ファイルの permissions.defaultMode
  3. 組み込みの標準

組み込みの標準は、v2.1.283以降なら、対話型のターミナルとVS Codeで auto です。それより前のバージョンでは、auto になるのはPro、Max、Teamのプランなどに限られる、と書かれています。ただし、auto が使えない状況（組織が止めている、対応外のモデル、など）では Manual で始まります。

確認を毎回求める動きに固定したい場合、公式の例は、~/.claude/settings.json に次のように書く方法です。

{
  "permissions": {
    "defaultMode": "default"
  }
}

次のセッションから、ステータスバーに manual mode on と出る、と公式にあります。なお、プロジェクトの .claude/settings.json に "auto" や "bypassPermissions" を書いても、効かない（自動では適用されない）と書かれています。リポジトリに入っている設定ファイルで、危険なモードに勝手に切り替わらないための仕組みだと読めますが、これは僕らの読みです。

autoモードは何をするのか

auto では、別のAI（「分類器」）が、実行の前に操作を見て、依頼の範囲を超えるものを止める、と公式は説明しています。標準で止められる例として、curl | bash のように、ダウンロードしてそのまま実行すること、機密データを外部に送ること、本番への配備、強制プッシュ（force push）などが挙がっています。同じ判断が3回続けて、または合計20回止まると、auto は一時停止して、確認を求める動きに戻る、と書かれています。

公式は警告も付けています。auto は確認を減らすが、安全を保証しない。信頼できる方向の作業で使い、慎重な操作の見直しの代わりにはしない、という趣旨です。使える条件にも、モデル（Opus 4.6以降、Sonnet 4.6以降など）、プロバイダ、組織の設定があり、使えないときは Manual に戻ります。

許可のルールを書く（allow、ask、deny）

モードが「基準」なら、ルールは「個別の例外」です。/permissions を開くと、ルールと、そのルールが書かれたファイルの一覧が見られ、追加や削除もできます。ルールは Tool または Tool(specifier) の形で書きます。

* は何にでも一致します。公式は、* を「サブコマンドの後ろ」に置くよう注意しています。Bash(git log *) は git log だけを許し、Bash(git *) は git のすべてを許してしまうからです。公式が載せている例は次のとおりです。

{
  "permissions": {
    "allow": ["Bash(npm run *)", "Bash(git commit *)"],
    "deny": ["Bash(git push *)"]
  }
}

秘密のファイルを読ませない例として、公式は、Read(./.env) と Read(./.env.*) を deny に入れた設定を示しています。ルールは、複数の設定ファイルで足し合わされます。どこかで deny されたものは、ほかの場所で allow しても通りません。

ルールの限界と、サンドボックスとの関係
  • Bashのルールは「書かれた形」に一致する。 公式の表では、Bash(curl *) は curl https://example.com を止めても、/usr/bin/curl ... や sh -c 'curl ...' は止めません。Bash(git push *) も、git -C . push origin main のような書き方は止められません。「セキュリティの境界」ではなく、普段の書き方を止めるものだ、と公式は説明しています。
  • ファイルの deny の範囲。 Read と Edit の deny は、Claudeの組み込みのファイル道具と、cat や sed など認識されたコマンドに適用されます。grep -r pattern . のように名前を出さずに読むコマンドや、Pythonなどのスクリプトが自分でファイルを開く場合には適用されません。OSの水準で全部のプロセスを止めたいなら、サンドボックスを使う、と書かれています。
  • サンドボックス。 /sandbox で有効にします。標準ではオフです。macOS、Linux、WSL2で使え、ネイティブWindowsでは使えません。コマンドの書き込みは、作業フォルダなどに限られ、ネットワークは許可したドメインだけになります。「auto-allow」を選ぶと、サンドボックスの中のコマンドは確認なしで実行され、「regular permissions」を選ぶと、普通の確認が残ります。ただし、サンドボックスが囲うのはシェルのコマンドだけです。ファイルの道具、MCPサーバー、フックは外で動く、と公式に書かれています。
  • 保護されたパス。 .git、.vscode、.idea、.claude（一部を除く）などのフォルダや、.bashrc、.zshrc、.mcp.json などのファイルへの書き込みは、bypassPermissions 以外では自動承認されません。allow ルールを書いても、この安全確認が先に働く、と書かれています。
  • 作業フォルダの追加。 起動したフォルダの外を使わせるには、--add-dir、/add-dir、設定の additionalDirectories を使います。これは「ファイルへのアクセス」を広げるもので、設定の読み込み範囲までは広げません。
  • 組織の管理。 管理者は、managed settings（管理設定）で、permissions.disableAutoMode や permissions.disableBypassPermissionsMode を "disable" にして、これらのモードを禁止できます。管理設定は、ユーザーの設定や旗では上書きできない、と書かれています。

信頼ダイアログと、プロジェクトの設定

リポジトリに入っている .claude/settings.json の permissions.allow と additionalDirectories は、そのフォルダを「信頼する」と答えたあとにだけ有効になります。公式は、ダイアログで、そのフォルダが与える許可の一覧を見られると説明しています。deny と ask は制限するだけなので、この対象外です。人の書いたプロジェクトを開くときは、このダイアログの内容を読むのが大事だ、というのが僕らの読みです（見立てです）。

どう選ぶか（僕らの整理）

ここからは、公式の記載を読んだうえでの僕らの整理で、見立てです。

状況 公式の記載から読める選び方
初めて、または他人のコードを開く default（Manual）で始め、出てくる確認を読む
自分のコードを書き換えさせ、あとで差分を見る acceptEdits
大きな変更の前に方針を見たい plan で計画を作らせ、承認してから実行
確認の連続が負担 auto。ただし「安全を保証しない」と公式が書いている
自動化（CI） dontAsk と --allowedTools で、許可を明示
完全に任せたい 隔離環境（コンテナなど）の中だけで bypassPermissions

気をつけること

出典