【Claude Code】defaultMode: autoが効かない？auto modeの権限まわりを整理した話

概要

今回はClaude Codeのauto mode（確認なしで操作を進められるモード）で、権限がどういう仕組みで判定されているかについて紹介していきます。

以前、settings.jsonでの自動承認の設計🔗 shinpinoshi.comについてまとめたことがあるんですが、その後「もっと手放しにできないか」とauto modeを試してみました。
ところが.claude/settings.jsonにいろいろ設定を書いたはずなのに、結局Claude Codeから「これ実行していいですか？」と聞かれる場面に何度も遭遇しました。

「あれ、ちゃんと設定したのに、なんで止まるんだろう」と思って権限の仕組みを1から調べ直したら、ちゃんと理由がありました。

それではやっていきましょう！

本記事はClaude Code v2.1.142時点の挙動をまとめたものです。
バージョンアップで仕様が変わる可能性があるため、実際に設定する際は公式ドキュメントも合わせて確認してください。

目次

きっかけ：auto modeにしたのに承認を求められる

Claude CodeにはdefaultModeという設定項目があって、これをautoにすると、コマンド実行のたびに確認プロンプトを挟まず、ほぼノータッチで作業を進めてくれるモードになります。

実際に試してみると、たしかに多くの操作はそのまま進んでくれるんですが、たまに「実行していいですか？」という普通の確認画面に戻ってしまうタイミングがあって、「あれ、auto modeのはずでは」と首をかしげることが何度かありました（- -;

このプロジェクトの.claude/settings.jsonにも"defaultMode": "auto"をちゃんと書いていたので、なおさら不思議だったんですよね。
結論から言うと、これは設定ミスというより、Claude Code側の仕様を自分がちゃんと理解していなかっただけでした。

分かったこと1：リポジトリ側のdefaultMode: autoは無視される

一番の気づきがこれです。

Claude Code v2.1.142以降、リポジトリの.claude/settings.json（および.claude/settings.local.json）に書いたdefaultMode: "auto"は無視されます。

実際に有効になるのは、ユーザー全体設定（~/.claude/settings.json）側のdefaultModeだけです。

リポジトリが自分自身にauto modeを与えられないようにするための仕様です。
悪意あるリポジトリの設定ファイルを開いただけでauto modeが勝手に有効化される、という事故を防ぐ狙いだと考えられます。

言われてみれば納得の仕様なんですが、知らずにプロジェクト設定側にだけdefaultMode: "auto"を書いていると、「設定したのに何も変わらない」状態になります。
このプロジェクトの設定にも"defaultMode": "auto"が残っていましたが、これは何も効いていない死んだ設定だったので削除しました。

auto modeを本当に有効化したい場合は、ユーザー全体設定（~/.claude/settings.json）側にdefaultMode: "auto"を書く必要があります。

分かったこと2：auto mode中は「丸ごと許可」ルールが無効化される

2つ目の気づきは、auto modeに入ったあとの許可ルールの扱いです。

auto modeに入ると、任意コード実行を許してしまうような広い許可ルールは自動的に無効化されます。

  • 無効化される例
    • Bash(*)（＝裸の"Bash"）
    • PowerShell(*)
    • ワイルドカード付きインタプリタ（Bash(python*)など）
    • Agentの許可ルール
  • 生き残る例
    • Bash(npm test)
    • Bash(git fetch *)のような狭いルール

つまり、"Bash"をallowに入れているだけでは、auto mode中は実質何もしていないのと同じです。
個々のコマンドは、Claude Code内部の「分類器（classifier）」による都度判定に回されることになります。

分類器を経由させたくない・確実に無条件で通したいコマンドがあるなら、狭いパターンとして明示的にallowへ追加しておく必要があります。
このあたりは下の図のように、denyと狭いallowルールがまず優先的に評価される、というイメージを持っておくとわかりやすいです。

auto mode中のコマンド実行判定フロー（deny→狭いallow→分類器の順）
auto mode中のコマンド実行判定フロー（deny→狭いallow→分類器の順）

分かったこと3：分類器が一定回数ブロックすると通常の確認プロンプトに戻る

3つ目が、今回の「結局承認を求められる」体感の正体だったと思われる挙動です。

分類器は既定でいくつかの操作を破壊的とみなしてブロックします。

  • ブロックされる操作の例
    • git reset --hard / git checkout -- . / git restore . / git clean -fd
    • git stash drop / git stash clear
    • force push
    • 既存ファイルの不可逆な削除

3回連続、または合計20回ブロックされると、auto modeが一時停止し、通常の承認プロンプトに戻ります。
このしきい値は設定で変更できません。

自分がauto modeで感じていた「結局承認を求められる」という違和感は、これが原因だった可能性が高いです。
設定の不備ではなく意図された安全機構なので、設定ファイル側で完全に消すことはできません。

現在の設定

上で分かったことを踏まえて整理した、現在の設定はこんな感じです。

プロジェクト設定 .claude/settings.json

.claude/settings.json

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
{
  "permissions": {
    "allow": [
      "Bash",
      "Bash(git fetch *)",
      "Bash(npm test)",
      "WebFetch",
      "WebSearch"
    ],
    "deny": [
      "Bash(rm -rf /)",
      "Bash(rm -rf ~)",
      "Bash(sudo *)",
      "Bash(npm publish*)",
      "Bash(curl * | sh)",
      "Bash(curl * | bash)"
    ]
  }
}

deny側は実際にはもう少し細かいパターンを並べていますが、要点は次の順で整理していることです。

  • allowの並び順
    • 「丸ごと許可（auto mode中は実質無効）」
    • → 「auto mode中も生き残る狭いルール」
    • → 「その他ツール」
  • denyのグルーピング
    • rm -rf系のドライブ/ホーム全消し
    • システム破壊コマンド（mkfs、dd、formatなど）
    • Windows版の削除コマンド
    • curl|shのようなパイプ実行攻撃

defaultModeはあえて書いていません。
リポジトリ側に書いても無視されるだけなので、書かないことで「auto modeの有効・無効はユーザー全体設定側で管理している」ことを明示している形です。

ユーザー全体設定 ~/.claude/settings.json（要点のみ）

個人環境固有のパスを多く含むため詳細は割愛しますが、要点だけ書くと次のとおりです。

  • defaultMode: “auto”
    • auto modeの実際の有効化はここで行っている
  • 機密ファイルのdeny
    • ~/.ssh、~/.aws、gh/gcloudの認証情報などの読み取り・編集を禁止
  • 信頼できる作業領域のallow
    • Read / Glob / Grepを無条件許可
    • 加えて、自分の開発用ワークスペースとして全面的に信頼しているフォルダ配下全体を対象にEdit / Write / NotebookEditを許可

締め

こんな感じで色々いじってますが、やはり難しいですね。
今回得られた教訓は以下の通りです。

  • 「広いallowルール」はauto mode中は思っているほど効いていない
    • 狭いパターンを積み増すほうが実効性が高い
  • プロジェクト設定にdefaultModeを書いても意味がない（autoの場合）
    • モードの既定値はユーザー全体設定側で管理する
  • 承認プロンプトが完全にゼロにならないのは仕様
    • 特に破壊的操作（git stash dropなど）は分類器が意図的に警戒している

「設定を疑う前に、まず仕様を疑ってみる」というのは、こういうツールを使いこなすうえでかなり大事だなと感じました。

以上となります。
もう開発用のPCを別で買おうかなと思う今日この頃（- -
それではお疲れさまでした。

エンジニアリング
Claude Code, エンジニアリング, セキュリティ