Claude CodeのAuto modeとbypassPermissions：確認を減らす前に決める境界

権限確認が多すぎるなら、まず試すべきは Auto mode と明示的な deny / ask ルールの組み合わせです。Bash コマンドの到達範囲も絞りたいならサンドボックスを追加します。bypassPermissions は確認を減らすための上位モードではなく、外側のコンテナや VM がすでに安全境界になっているときだけ使う選択肢です。

どちらも画面上の確認を大きく減らしますが、内部の意思決定は異なります。Auto mode では別の分類器が操作を確認します。bypassPermissions では通常の権限確認と安全チェックを通りません。

「自動実行」の中身は同じではない

Anthropic の現在の権限モード仕様では、Auto mode は実行前に別モデルの classifier が操作を評価します。依頼の範囲を超える変更、未知のインフラ、破壊的な操作、Claude が読んだ悪意ある内容に誘導されたような操作はブロック対象です。明示した ask ルールは引き続き確認を出し、permissions.deny は classifier より前に全モードで働きます。

一方、bypassPermissions は通常の権限プロンプトと安全チェックを無効にし、保護パスへの書き込みを含む tool call を直ちに実行します。次の二つは同じ意味です。

bash
claude --permission-mode bypassPermissions
claude --dangerously-skip-permissions

ただし、製品内のすべての不変条件が消えるわけではありません。明示的な ask、組織が確認を必須にした connector、ユーザー操作を必要とする tool、critical path を対象にした rm / rmdir、一部の cross-session message には個別の扱いが残ります。deny ルールも有効です。これは仕様を正確にするための例外であって、bypass を安全にする保護ではありません。公式説明は prompt injection や意図しない操作への保護がないと明記しています。

Auto mode も安全を保証しません。classifier は文脈に基づく判断を行うため、見逃しと過剰ブロックの両方があり得ます。通過した操作が正しい実装であることや、業務上承認済みであることまで証明するものではありません。

タスクの長さではなく被害範囲で選ぶ

一晩かかるテストより、数分の production migration の方が大きな権限を使う場合があります。モードを選ぶ前に、次を具体化してください。

1. 誤ったコマンドが触れられるファイル、ネットワーク、クラウド資源は何か。
2. どの credential が存在し、それぞれ何を変更できるか。
3. ホストを復旧せず環境だけ破棄して作り直せるか。
4. 不可逆または外部への操作の前に、人の checkpoint が残るか。

自分が管理し、最後に diff とテストを確認する通常の repository なら Auto mode が実用的です。classifier を残しつつ、確認疲れを減らせます。

未知のコード、個人情報、production インフラ、目的が変化中の作業は Manual または Plan が適します。必要なのは追加の自動化ではなく、人が意味を判断する停止点です。

固定コマンドだけを走らせる CI なら dontAsk も候補です。事前承認済み tool だけを実行し、それ以外を拒否するため、文脈判断より監査しやすい契約になります。

bypassPermissions は外部隔離が実際の境界である場合だけです。公式の前提はインターネットに接続しない container、VM、dev container。non-root で動かし、host の home や credential を mount せず、作業 copy と結果 directory だけを渡し、環境を使い捨てにします。Linux と macOS では、認識済み sandbox の外で root / sudo による bypass 起動が拒否されますが、このチェック自体は隔離ではありません。

課題が terminal 終了後の継続や中断後の復旧なら、権限モードだけでは解決しません。Claude Code の長時間タスク設計で runtime、永続状態、完了証拠を分けて考えてください。

Auto modeは有効になるscopeに設定する

一回の terminal session なら明示的に起動できます。

bash
claude --permission-mode auto

個人の terminal 既定値は ~/.claude/settings.json に置きます。

json
{
  "permissions": {
    "defaultMode": "auto",
    "deny": [
      "Bash(git push --force *)",
      "Bash(terraform destroy *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(terraform apply *)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "allowUnsandboxedCommands": false,
    "failIfUnavailable": true
  }
}

現在の terminal 契約では、repository 内の .claude/settings.json や .claude/settings.local.json に書いた defaultMode: "auto" は反映されません。checkout した repository 自身が Auto mode を有効化できないためです。VS Code などは開始モードの制御が別なので、使っている surface で確認してください。

deny / ask の例は、公式の権限ルール構文に従って実際の command と target に合わせます。広い allow rule は、classifier が見る前に想定外の危険な引数まで承認することがあります。文脈に関係なく禁止する操作は managed permissions.deny に置く方が明確です。

Auto mode の environment には、信頼する repository、社内 domain、bucket、package registry、機密性の高い remote target を記述できます。保存した file を読むだけで precedence を推測せず、merge 後の有効値を出力します。

bash
claude auto-mode config

組み込みルールは claude auto-mode defaults、カスタムルールの曖昧さは claude auto-mode critique で確認できます。Auto の対応 model、provider、version、既定モードは変化するため、設定があることと利用可能であることを同一視しないでください。

承認レイヤーの下に隔離レイヤーを置く

Auto mode は「その操作を誰が承認するか」を決めます。Bash sandboxは、承認後の Bash と子 process が「実際にどの file と network に届くか」を OS レベルで制限します。

内蔵 sandbox は macOS、Linux、WSL2 で使え、native Windows は WSL2 が必要です。fail-closed に近づけるには、次を確認します。

• 書き込み先を repository と session temp に限定する。
• 必要な domain だけを network allowlist に入れる。
• SSH、cloud credential、高権限 token を deny または mask する。
• allowUnsandboxedCommands: false で host 上の再実行を禁止する。
• failIfUnavailable: true で sandbox 不成立時に停止する。

Bash sandbox の対象は Bash と子 process であり、Claude Code の全 tool ではありません。無人の bypass 実行では、最終境界は依然として外部 container または VM です。承認と到達可能範囲は別々に検証します。

離席する前に実効状態を確認する

Auto mode の可用性や開始時の mode は、version、plan、model、provider、feature flag、組織設定、interface によって変わります。起動 command ではなく次の実状態を見ます。

1. status bar の mode 表示。CLI は Shift+Tab で session に存在する mode を確認できます。
2. /permissions の effective allow / ask / deny と直近の拒否。
3. claude auto-mode config の統合済み classifier context。
4. /sandbox の filesystem、network、mode、unsandboxed retry。

Auto mode が繰り返し block すると、interactive session は人への prompt に戻る場合があります。permission prompt tool のない non-interactive -p では拒否された操作は実行されませんが、他の処理は続くことがあります。process が動いていることは完了証拠ではありません。無人実行には観測可能な成功条件と失敗 artifact を用意してください。

方向を信頼しつつ reviewer を残すなら Auto mode。固定 allowlist なら dontAsk。人の判断が必要なら Manual / Plan。host、internet、credential、永続データを agent から切り離せたときだけ bypassPermissions を検討する、という順序が安全です。