Claude Code v2.1.283 以降、対話型のターミナルと VS Code では auto mode が起動時の既定モードになりました。承認ダイアログが減って快適になる一方、「誰も確認していないのに push や削除が走っているのではないか」という不安が情シス担当に残ります。
本記事では、auto mode が何を自動で止め、何を素通しするのかを公式ドキュメントで確認し、少人数の組織が最初に決めるべき統制を整理します。権限ルール全般の考え方は Claude Codeの権限設計 を先に読むと理解しやすくなります。
auto modeとは何か、何が違うのか
auto mode は、人の代わりに分類器（classifier）が各操作を審査するモードです。危険と判定した操作は実行前に止まります。
従来の default モードは、ファイル編集やシェル実行のたびに人へ確認します。auto mode ではこの確認を第二のモデルである分類器が代行し、安全なら実行、危険ならブロックします。分類器を通る前に評価される deny ルールと ask ルールは、auto mode でも有効です。
ただし auto mode は人の確認を完全に置き換えるものではありません。Anthropic も、--dangerously-skip-permissions よりリスクは下がるがゼロにはならず、隔離環境での実行を推奨すると説明しています。
分類器は既定で何を止めるのか
既定では curl | bash、本番デプロイ、force push、権限付与、シークレットの外部送信などがブロックされます。
信頼されるのは作業ディレクトリと、セッション開始時に設定済みのリモートだけです。それ以外は外部扱いになります。ブロック対象の主なものは次のとおりです。
- コードをダウンロードして即実行する操作（
curl | bash） - 本番へのデプロイとマイグレーション
- force push と
git reset --hardなどの変更破棄 - IAM やリポジトリ権限の付与
- シークレットや機密データの外部送信
一方、作業ディレクトリ内のファイル操作、lockfile 記載の依存関係のインストール、参照のみの HTTP リクエストは既定で許可されます。作業中のリポジトリへの push も、デプロイ先と見なされるブランチ名（production など）を除き、確認なしで通ります。「push は必ず人が見る」を守りたい組織は、追加の設定が必要です。
人の承認を確実に残すにはどう設定するか
確実に人の承認を残す手段は
permissions.ask、確実に止める手段はpermissions.denyです。会話での指示は保証になりません。
制約の強さに応じて、次の3つを使い分けます。
| 目的 | 仕組み | auto mode での挙動 |
|---|---|---|
| 実行前に必ず確認 | permissions.ask | 分類器が自動承認できず、必ず確認が出る |
| 絶対に実行させない | permissions.deny | 分類器の前でブロック。上書き不可 |
| 今回のセッションだけ慎重に | 会話で「push は待って」と伝える | 分類器が尊重するが、永続しない |
会話での指示は、コンテキスト圧縮でその発言が消えると失われます。永続させたい制約は設定ファイルに書きます。push と PR 作成に人の確認を挟む最小例は次のとおりです。
``json``
{
"permissions": {
"ask": ["Bash(git push )", "Bash(gh pr create )"]
}
}
git -C のように書き方を変えた push は、この規則に一致しません。完全な検査が必要なら PreToolUse フックを併用します。フックによる監査記録は Claude Codeのhooksで監査証跡を自動記録する で解説しています。
組織としてauto modeをどこまで許可するか
組織単位の統制は managed settings で行います。
disableAutoModeで auto mode 自体を無効化でき、分類器の追加設定は個人設定と管理設定からだけ読まれます。
統制の選択肢は3段階です。
- 全面禁止: managed settings で
permissions.disableAutoModeを"disable"にします。Shift+Tabの切替から auto が消え、起動時指定しても手動承認モードで始まります - 許可して補強: 管理設定に
denyとaskを置き、autoMode.environmentで自社の GitHub 組織や社内ドメインを信頼先として登録します - 個人任せ: 非推奨です。信頼先の登録漏れによるブロックが頻発し、現場が
bypassPermissionsに流れやすくなります
なお bypassPermissions は permissions.disableBypassPermissionsMode で禁止できます。公式も、このモードはプロンプトインジェクションや意図しない操作への防御を持たないと明記しています。
autoMode の設定はプロジェクトの .claude/settings.json からは読まれません。リポジトリに悪意ある許可ルールを仕込まれる経路を塞ぐ仕様です。ルールを書き換えるときは、"$defaults" を配列に含めることが重要です。省略すると既定の soft_deny（force push や本番デプロイの禁止など）が丸ごと置き換わります。
設定後は claude auto-mode config で実効設定を確認し、claude auto-mode critique で自作ルールの曖昧さを点検できます。
運用で何を見るべきか
ブロックが連続3回、または累計20回に達すると auto mode は一時停止し、人の承認に戻ります。この回数は変更できません。
運用では次の3点を週次で確認すれば十分です。
/permissionsの Recently denied タブで、何がなぜ止まったか- 同じ宛先が繰り返し止まる場合は、
autoMode.environmentへの登録漏れ（登録は GitHub 組織・社内ドメイン・バケット単位） PermissionDeniedフックでブロックの入力内容を記録に残す
導入初期は、安全が確認できた操作から少しずつ autoMode.allow に足します。逆方向、つまり一度緩めた設定を締め直すのは難しいため、最初は厳しめに始めるのが定石です。さらに隔離実行が必要なら Claude CodeのBashサンドボックス実装ガイド を併用してください。
参考
- Choose a permission mode - Claude Code Docs
- Configure auto mode - Claude Code Docs
- Auto mode for Claude Code - Claude Blog
まとめ
auto mode は便利ですが、統制の代わりにはなりません。deny・ask・managed settings の3点を先に固めてから使います。
- push や PR 作成に人の確認を残すなら
permissions.ask - 絶対に走らせない操作は
permissions.deny - 組織で使うなら
disableAutoModeと信頼先登録の方針を決める
Kuu株式会社では、Claude Code を含む AI エージェントの権限設計と運用定着を伴走支援しています。設定の棚卸しから始めたい方は、AI Ops サービス をご覧ください。