Claude Media
Claude Code dontAskモードとは — 承認済みツールだけを自動実行する設定

Claude Code dontAskモードとは — 承認済みツールだけを自動実行する設定

dontAskモードは事前許可したツール呼び出しだけを実行し、他は全部拒否する権限モードです。CI組み込みの手順とよくあるつまずきをまとめます。

dontAskモードは、事前に許可したツール呼び出しだけを実行し、それ以外の操作をすべて拒否する権限モードです。確認プロンプトを一切出さないため、人が付き添えないCIパイプラインや、動作範囲を厳密に絞りたいスクリプト実行を想定して用意されています。autoモードのように分類器(2つ目のモデル)が判定を挟むことはありません。通るのはpermissions.allowルール・読み取り専用のBashコマンド・PreToolUseフックが許可した呼び出しだけです。

dontAskモードとは

dontAskモードは、確認を一切行わない権限モードのうち最も許可範囲が狭いモードです。他のモードは「確認する」か「分類器に判定させる」かの違いで動作範囲を広げますが、dontAskモードは判定そのものを行いません。呼び出しがpermissions.allowルール、組み込みの読み取り専用Bashコマンド、PreToolUseフックの許可のいずれにも一致しなければ、自動的に拒否されます。

ステータスバーには⏵⏵ don't ask onと表示され、セッションは入力を待たずに動き続けます。ロックダウンされたCI環境や、実行できる操作をあらかじめ台帳化しておきたい制限環境向けのモードです。

前提 — 通るものと拒否されるものを正確に区別する

このモードで重要なのは、「自動実行する」ではなく「事前許可以外は全部止める」という設計です。通る呼び出しは3種類だけです。

  • permissions.allowルールに一致する呼び出し
  • 組み込みの読み取り専用Bashコマンド(ls cat echo pwd head tail grep find wc which diff stat du cd、読み取り系のgitなど)
  • PreToolUseフックが明示的に許可した呼び出し

読み取り専用コマンドの集合は設定で変更できません。特定コマンドに確認や拒否を挟みたい場合は、そのコマンドに対して個別のaskまたはdenyルールを追加します。

拒否される側で見落としやすいのは次の4点です。

  1. 明示的なaskルールに一致する呼び出しは、確認されるのではなく拒否されます。dontAskモードには確認という選択肢自体が無いためです
  2. AskUserQuestionツールは常に拒否されます。回答を集める手段が無いモードなので、allowルールが一致していても実行できません
  3. 組織がaskに設定したconnectorツールと、_meta["anthropic/requiresUserInteraction"]が付いたMCPツールも、allowルールが一致していても拒否されます(この扱いはClaude Code v2.1.199以降)
  4. .git .claudeなどの保護パスへの書き込みと、rm / rmdirによるクリティカルパス(ファイルシステムのルート、ホームディレクトリ、作業ディレクトリの親など)の削除は、allowルールやPreToolUseフックのallow返答があっても拒否されます
保護ディレクトリ・保護ファイルの一覧

保護ディレクトリ: .git .config/git .vscode .idea .husky .cargo .devcontainer .yarn .mvn .claude(.claude/worktreesを除く)

保護ファイル: .gitconfig .gitmodules、シェル起動ファイル群(.bashrc .zshrc等)、.npmrc .yarnrc .pnpmfile.cjs等のパッケージマネージャー設定、.bazelrc系、.pre-commit-config.yaml lefthook.yml系、gradle-wrapper.properties maven-wrapper.properties.devcontainer.json.ripgreprc pyrightconfig.json.mcp.json .claude.json

使い方 — 起動からCI組み込みまで

単発で起動する

claude --permission-mode dontAsk

許可するツールを明示する(headless実行)

CIで使う場合は-pの非対話実行と組み合わせ、--allowedToolsで実行させたい範囲をピンポイントで許可します。

claude -p "テストを実行して結果を報告して" \
  --permission-mode dontAsk \
  --allowedTools "Bash(npm test)" "Bash(npm run lint)" "Read"

Bash(git diff *)のように末尾へスペース区切りで*を付けると前方一致になります。スペースを省くとBash(git diff*)になりgit diff-indexのような別コマンドまで拾ってしまうため、範囲を絞るときはスペースの有無を必ず確認します。

settings.jsonで既定化する

セッションのたびにフラグを渡す代わりに、permissions.defaultModeで既定化できます。

{
  "permissions": {
    "defaultMode": "dontAsk",
    "allow": [
      "Bash(npm test)",
      "Bash(npm run lint)",
      "Read"
    ]
  }
}

allowedToolsとの違いは効く範囲だけです。フラグはそのセッション限定、settings.jsonはファイルが読み込まれる全セッションに効きます。CIランナーのリポジトリに固定設定として置くならsettings.json側、ワンショットの実行なら--allowedToolsが向いています。

PreToolUseフックで例外を作る

PreToolUseフックは、dontAskモードを含むすべての権限モードで、権限モードの判定より先に発火します。これを使うと「Bashは丸ごと許可しつつ、特定のコマンドだけ弾く」という設計が可能です。フックが終了コード2で拒否を返すと、その呼び出しはallowルールが一致していても止まります。逆にフックが許可を返しても、明示的なdenyルールが一致する呼び出しは通りません。deny優先の原則はdontAskモードでも変わらないためです。

dontAskモードは他モードとどう違うか

主要な5つのモードは、確認をどこまで省くかと、判定の主体が誰かで分かれます。

モード確認プロンプト判定の主体向く用途
default(Manual)確認プロンプト都度確認判定の主体向く用途慎重な作業、不慣れなコードベース
acceptEdits確認プロンプトファイル編集と一般的なファイル操作は自動承認判定の主体ルール(固定)向く用途ローカルでの反復作業
auto確認プロンプト大半を自動承認判定の主体分類器(2つ目のモデル)向く用途手を離しつつ監視は残したい作業
dontAsk確認プロンプト一切なし(事前許可以外は拒否)判定の主体ルール一致のみ向く用途ロックダウンされたCI・スクリプト
bypassPermissions確認プロンプトほぼ一切なし判定の主体なし向く用途隔離済みコンテナ・VM限定

bypassPermissionsとの違いは「拒否か許可か」の初期値です。bypassPermissionsは保護パスへの書き込みも含めてほぼすべてを通す設計なので、インターネットに繋がらないコンテナやVMのような、Claude Codeがホストを壊せない環境専用です。dontAskモードは逆に、あらかじめ列挙したものしか通しません。CI環境のようにネットワークもホストの認証情報も生きている場所では、dontAskモードのほうが安全側の初期値になります。

autoモードとの違いは判定の主体です。autoモードの分類器はセッションの文脈を読んで動的に判断しますが、判定用のモデル呼び出しが挟まる分、往復のレイテンシとトークン消費が発生します。dontAskモードはルール一致だけで即座に決まるので、CIのように毎回同じ操作を繰り返す用途ではこちらのほうが速く、挙動も予測しやすくなります。

よくあるつまずき

allowルールに書いたのに動かない」。原因のほとんどは前提セクションの4点のどれかです。保護パスへの書き込み、AskUserQuestion、組織がask設定にしたconnectorツール、requiresUserInteraction付きのMCPツールが対象になります。これらはallowルールの一致に関係なく拒否されるため、まずどの分類に当たるかを切り分けます。

モード切り替え中に判定待ちだった操作が急に拒否されるautoモードで分類器の判定が返ってくる前にdontAskへ切り替えると、Claude Codeはその判定結果を新しいモードでは要求しなかったものとして破棄します。dontAskモードでは確認という選択肢が無いため、判定待ちだった操作はそのまま拒否に回ります。

Claude Code on the webではdefaultMode: "dontAsk"が効かない。クラウドセッションは設定ファイルのdontAsk指定を黙って無視し、モードのドロップダウンで選ばれているモードのまま起動します。CI相当の用途でこのモードを使いたい場合は、CLI上のセッションかローカルのCIランナーで動かします。

サブエージェントにも同じ制約が及ぶ。サブエージェントのfrontmatterでpermissionMode: dontAskを指定すると、そのサブエージェントも同じ判定基準で動きます。基準はallowルール・読み取り専用コマンド・フックのみで、親セッションが別のモードでもサブエージェント単位でdontAskに絞れます。

Desktopアプリのモードセレクターには出てこない。dontAskモードはCLI専用で、Desktopアプリの選択肢には表示されません。Shift+Tabの切り替えサイクルにも入らないため、使うときは--permission-mode dontAskフラグかdefaultMode設定で明示します。

よくある質問

dontAskモードとbypassPermissionsモードはどちらが安全ですか

用途が違います。dontAskモードは列挙した操作以外を拒否するため、ネットワークや認証情報が生きている環境向けです。bypassPermissionsモードは保護パスへの書き込みも含めてほぼすべてを通すため、ホストにダメージを与えられない隔離済みコンテナ・VM専用に限定します。

dontAskモードでAskUserQuestionを使いたい場合はどうすればいいですか

できません。dontAskモードは回答を集める仕組みそのものを持たないため、AskUserQuestionは常に拒否されます。対話的な確認が必要な工程が残っている場合は、その工程だけdefaultautoモードのセッションに分けます。

--allowedToolssettings.jsonpermissions.allowはどちらを使えばいいですか

一度きりの実行やCIジョブごとに範囲を変えたいなら--allowedToolsが向きます。リポジトリ全体で同じ許可範囲を使い回すならsettings.jsonpermissions.allowが向いています。両方指定した場合、どちらの一致でも許可されます。

読み取り専用コマンドの一覧を自分で増やせますか

増やせません。組み込みの読み取り専用セットは固定です。個別のコマンドに確認や拒否を挟みたい場合は、そのコマンドに対するaskまたはdenyルールを別途追加します。

まとめ

dontAskモードは、事前に許可した操作だけを実行し、それ以外を自動で拒否する設計のモードです。CIパイプラインのように人が付き添えず、かつホストの認証情報やネットワークが生きている環境では、確認を省きながらも実行範囲を厳密に絞れる選択肢になります。--allowedToolssettings.jsonpermissions.allowで許可範囲を決め、PreToolUseフックで例外を作り込む、という組み合わせが基本形です。保護パスへの書き込みやAskUserQuestionのようにallowルールでも上書きできない拒否があることは、設定前に把握しておく価値があります。

権限モードの全体像とpermissions設計はClaude Code settings.json完全ガイドautoモードの判定基準はauto mode分類器は何を止めているかにあります。CIへの組み込み手順はClaude CodeをGitHub Actionsに組み込む、CI実行を多層で守りたい場合はClaude Codeのサンドボックス設計が扱っています。

この記事を共有:XはてブLinkedIn