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

dontAskモードは、事前に許可したツール呼び出しだけを実行し、確認が必要になる呼び出しをすべて拒否する権限モードです。確認プロンプトを出さないので、人が付き添えないCIや、動作範囲を厳密に絞りたいスクリプト実行に向きます。autoモードのように分類器(2つ目のモデル)が判定を挟むことはありません。

人に確認せず、モデルにも判定させない。残るのはルールの一致だけです。設定の書き方より先に、どの呼び出しが通り、どの呼び出しが「allowを書いても」止まるのかを押さえておくと、CIで原因不明の拒否に悩まずに済みます。

dontAskモードとは

他のモードは「人に確認する」か「分類器に判定させる」かの違いで動作範囲を広げます。dontAskモードはそのどちらも持たず、確認が必要になった時点で自動拒否します。ステータスバーには⏵⏵ don't ask onと表示され、セッションは入力を待たずに進みます。

Shift+Tabの切り替えサイクルには入りません。使うときは--permission-mode dontAskか、設定ファイルのpermissions.defaultModeで明示します。

手元のclaudeで確認できること

v2.1.286のclaude --helpでは、--permission-modeの選択肢にdontAskが含まれていました。

claude --version
claude --help | grep -A3 -e "--permission-mode"

2.1.286 (Claude Code)
  --permission-mode <mode>              Permission mode to use for the session
                                        (choices: "acceptEdits", "auto",
                                        "bypassPermissions", "manual",
                                        "dontAsk", "plan")

選択肢にdefaultではなくmanualが出ている点に注意してください。確認を都度求めるモードの設定値はdefaultのままですが、ラベルとmanualという別名はv2.1.200以降のものです。CIのスクリプトで古いバージョンのClaude Codeが混ざる場合は、defaultを書いておくほうが安全です。同じヘルプには--allowedToolsと--disallowedToolsもあり、どちらも「Bash(git *) Edit」のようにカンマかスペースで区切って渡せます。

ヘルプの冒頭には、claudeが既定で対話セッションを始め、-p/--printを付けると非対話で動くと書かれています。CIの記述例で-pが毎回付くのはこのためです。

確認したのは起動前のヘルプ出力までです。dontAskモードでの実際の拒否は、モデルを呼ぶ実行が必要になるため、この記事の確認範囲には含めていません。以降の挙動は、公式の権限モードとpermissionsのページに書かれている内容です。

通る呼び出しと拒否される呼び出し

このモードの本質は、自動実行ではなく「事前許可以外は全部止める」ことです。通る呼び出しは次の3種類です。

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

allowを書いても拒否される4つの場合

見落としやすいのは、次の4つです。

1. 明示的なaskルールに一致した呼び出しは、確認されずに拒否されます。確認という選択肢自体が無いためです
2. AskUserQuestionツールは、allowルールが一致していても常に拒否されます。回答を集める手段が無いからです
3. 組織がaskに設定したconnectorツール(その設定がClaude Codeに届くセッションの場合)と、_meta["anthropic/requiresUserInteraction"]が付いたMCPツールも拒否されます。後者の扱いはv2.1.199以降です
4. rm / rmdirによるクリティカルパス(ファイルシステムのルートやホームなど)の削除は、allowルールやPreToolUseフックの許可があっても拒否されます

保護パスへの書き込みは、公式の一覧表でdontAskの行が「Denied」になっています。.git .claudeなどが対象です。安全チェックはallowルールの評価より先に走るので、allowを書いても通りません。

Windowsで使う場合は、PowerShellのRemove-Itemにも同じ種類の拒否があります。作業ディレクトリかその親を-Recurse付きで消す呼び出しは、dontAskモードでは拒否されます。bypassPermissionsではこの確認が省かれるので、モードによって結果が分かれる点です。

読み取りの範囲にも注意が要ります。読み取り専用コマンドは確認なしで動きます。ただしpermissions.blockReadsOutsideWorkingDirectoriesが有効だと話が変わります。

この設定は、すべての権限モードで作業ディレクトリの外へのアクセスを止めます。Read Grep Glob LSPが対象です。bypassPermissionsを含むすべてのモードで拒否され、ディレクトリは/add-dirで加えるよう案内されます。CIランナーで別のチェックアウト先を読ませるなら、--add-dirで渡します。

1回の呼び出しがどう判定されるか

呼び出しごとの流れは次の3段です。ルールの評価順は「deny、ask、allow」で、最初に一致したものが結果を決めます。具体的なルールのほうが優先されることはありません。

「Bashは丸ごと許可しつつ、特定のコマンドだけ弾く」設計は、この順序のおかげで成り立ちます。allowにBashを置き、危険なコマンドをdenyルールかフックの拒否で止めます。

使い方 — 起動から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 *)はgit diffそのものとgit diff HEADに一致しますが、git diff-indexには一致しません。スペースを省いたBash(git diff*)はgit diff-indexまで拾います。公式の例でもBash(ls *)がlsofに一致しない一方で、Bash(ls*)は一致するとされています。範囲を絞るときはスペースの有無を必ず確認します。

settings.jsonで既定化する

フラグを毎回渡す代わりに、permissions.defaultModeで既定化できます。

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

--allowedToolsはそのセッション限定、settings.jsonはファイルが読み込まれる全セッションに効きます。ローカルで繰り返し使うならsettings.jsonが手軽です。CIの-p実行では、--allowedToolsで渡すのが確実です。

プロジェクトの.claude/settings.jsonに書いたpermissions.allowは、フォルダーを信頼するダイアログを承認するまで使われません。claude -pはこのダイアログを出しません。フォルダーが信頼済みでなければ、チェックイン済みのallowルールは使われず、stderrにthis workspace has not been trustedの警告が出ます。

信頼済みにする手段として、公式は~/.claude.jsonのprojects["<path>"].hasTrustDialogAcceptedをtrueにする方法を示しています。denyとaskのルールは制限側なので、この影響を受けません。

CIに入れる前の確認項目

CIで初めてdontAskを使うときは、次の4点を先に見ておくと手戻りが減ります。

1. 使うClaude Codeのバージョン。MCPのrequiresUserInteraction付きツールの拒否はv2.1.199以降、manualという別名はv2.1.200以降です
2. allowルールをプロジェクトの.claude/settings.jsonに置く場合、-pではフォルダーが信頼済みでないと使われません。CIでは--allowedToolsで渡します
3. 実行環境がクラウドセッションではないこと。クラウドはdefaultMode: "dontAsk"を無視します
4. 確認や拒否を挟みたいコマンドが、読み取り専用の集合に入っていないこと。入っているならaskかdenyのルールを足します

askルールはdontAskでは拒否として働くので、「確認したい操作を拒否に倒す」書き方としても使えます。ただし意図を明確にしたいなら、denyルールのほうが読み手に伝わります。

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

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

bypassPermissionsとの差は、通すか拒否するかの初期値です。

autoモードとの違いは判定の主体です。autoの分類器はセッションの文脈を読んで動的に判断します。dontAskはルールの一致だけで決まるので、毎回同じ操作を繰り返すCIでは挙動が読みやすくなります。サンドボックス化Bashの確認省略ならautoAllowBashIfSandboxedが使えます。

症状から探す — よくあるつまずき

allowルールに書いたのに動かない

まず上の4つのどれに当たるかを切り分けます。askルールと衝突している場合は、askがallowより先に評価されるため、拒否に変わります。

モード切り替え中に判定待ちだった操作が急に拒否される

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

Claude Code on the webではdefaultMode: "dontAsk"が効かない

クラウドセッションは設定ファイルのdontAsk指定を黙って無視し、モードのドロップダウンで選ばれているモードのまま起動します。公式が挙げる理由は、チェックイン済みの設定でクラウドセッションをbypassPermissionsで起動させないためです。CI相当の用途ならCLIのセッションかローカルのCIランナーで動かします。

サブエージェントのモードが指定どおりにならない

frontmatterのpermissionModeが効くかどうかは、親セッションのモードで決まります。

bypassPermissionsを指定したサブエージェントは、親がdefaultでもdontAskでもplanでも、親のモードを引き継ぎます。この例外はv2.1.267以降の挙動です。

プラグイン由来のサブエージェントは、hooks mcpServers permissionModeのfrontmatterが読み込み時に無視されます。親のモードに関係なく、permissionModeは効きません。

Desktopアプリでは使えない

Desktopのドキュメントには、dontAskはCLIでのみ使えると明記されています。セレクターに並ぶのはManual・Accept edits・Plan・Auto・Bypass permissionsの5つです。CIやスクリプトでは、CLIから--permission-mode dontAskで起動します。

まとめ

dontAskモードは、確認を省きながら実行範囲を絞るための設計です。--allowedToolsかpermissions.allowで許可範囲を決め、例外はdenyルールかPreToolUseフックで作り込みます。CIでは許可を--allowedToolsでコマンドラインに固定し、プロジェクトのsettings.jsonはローカル用と割り切ると、信頼ダイアログの有無に左右されない組み方になります。

権限モードの全体像とpermissions設計はClaude Code settings.json完全ガイド、autoモードの判定基準はauto mode分類器は何を止めているかにあります。CIへの組み込み手順はClaude CodeをGitHub Actionsに組み込む、CI実行を多層で守りたい場合はClaude Codeのサンドボックス設計が扱っています。--permission-modeフラグが受け付ける値の一覧や設定ファイルとの優先順位、セッション再開時の挙動はClaude Codeの--permission-modeで起動モードを指定するにまとめています。