はじめに
この記事は、Claude Code をスケジュール実行や CI などの自動実行で回していて、2026 年 8 月 14 日の auto mode 既定化で手元のガードレールが外れないか気になっている開発者向けです。
権限モードが変わると「承認プロンプトで気付く」という前提が崩れます。そこで、permissions.deny と PreToolUse フックという 2 つのガードが、モードごとにどう振る舞うかを Claude Code 2.1.228 で実測しました。結果は先に置きます。
| 権限モード | deny 対象（curl） |
フック対象（wget） |
ガードなしの curl
|
|---|---|---|---|
manual |
ブロック（deny） | ブロック（フック） | 承認要求のため実行されず |
auto |
ブロック（deny） | ブロック（フック） | 実行され HTTP 200 |
acceptEdits |
ブロック（deny） | ブロック（フック） | 未測定 |
dontAsk |
ブロック（deny） | ブロック（フック） | ブロック（permission_denied） |
plan |
Bash 自体が実行不可 | Bash 自体が実行不可 | 未測定 |
bypassPermissions |
起動できず（root 実行のため） | 同左 | 同左 |
実行できた 4 モード（manual / auto / acceptEdits / dontAsk）では、deny ルールとフックの両方が例外なくブロックしました。変わったのは「ガードを置いていないコマンドが走るかどうか」だけです。
8 月 14 日に何が既定になるのか
公式ドキュメントの Week 32 ダイジェストに、次の告知があります。
Starting August 14, auto mode is the default permission mode for new sessions on Pro, Max, and Team plans.
（出典: https://code.claude.com/docs/en/whats-new/2026-w32 ）
権限モードのリファレンスにも同じ記述があり、あわせて次の 2 点が明記されています（出典: https://code.claude.com/docs/en/permission-modes ）。
- 自分で
defaultModeを設定している場合、その設定は維持される（一度きりの切り替えプロンプトを承認した場合を除く） - 組織が管理している既定モードは変更されない
auto mode は、承認プロンプトの代わりに専用の分類器モデルが実行前の行動を審査するモードです。依頼の範囲を超える権限昇格、認識していないインフラへの操作、Claude が読み込んだ敵対的コンテンツに誘導された操作をブロックします。明示的な ask ルールは auto mode でもプロンプトを出します。
自動実行の観点で影響が大きいのは、既定の許可範囲です。同リファレンスによると、auto mode の既定では 作業中リポジトリのどのブランチへの push もプロンプトなしで実行されます（既定ブランチを含む）。例外は production や gh-pages のように名前でデプロイ・公開先と判別できる非既定ブランチで、これは既定許可の対象外として分類器が個別に判断します。push の内容自体は他のルールでも審査され、リモート側のブランチ保護も引き続き有効です。同時に「permissions.deny ルールは、すべてのモードで特定ブランチへの push をブロックできる」とも書かれています。つまり 8 月 14 日以降、push の歯止めを承認プロンプトに期待する設計は成立しません。
検証方法
検証は 2 つの最小プロジェクトを作り、ヘッドレス実行（claude -p）でモードだけを差し替える対照実験にしました。
ガードあり側の設定は次のとおりです。deny ルールで curl を、PreToolUse フックで wget を止めます。
{
"permissions": {
"deny": ["Bash(curl:*)"]
},
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{ "type": "command", "command": "$CLAUDE_PROJECT_DIR/.claude/hooks/block-wget.sh" }
]
}
]
}
}
フック本体は、標準入力に wget が含まれていたら終了コード 2 で拒否するだけの 6 行です。
#!/usr/bin/env bash
input=$(cat)
if echo "$input" | grep -q "wget"; then
echo "[hook] wget is blocked by PreToolUse hook" >&2
exit 2
fi
exit 0
比較対象（ベースライン）は .claude/settings.json が {} だけのプロジェクトです。どちらにも同じ指示を与えました。
claude -p "Run these two bash commands, one at a time, and report what happened.
1) curl -sS -o /dev/null -w '%{http_code}' https://example.com
2) wget --version | head -1
..." --permission-mode auto --output-format text < /dev/null
検証環境は Claude Code 2.1.228、Linux コンテナ（GNU Wget 1.21.4 が同梱）、実行ユーザーは root です。
結果1: ガードあり側は 4 モードとも止まった
manual / auto / acceptEdits / dontAsk の 4 モードで、返ってきた文言は完全に同一でした。
CURL: blocked:Permission to use Bash with command curl -sS -o /dev/null -w '%{http_code}' https://example.com has been denied.
WGET: blocked:PreToolUse:Bash hook error: [$CLAUDE_PROJECT_DIR/.claude/hooks/block-wget.sh]: [hook] wget is blocked by PreToolUse hook
deny ルール由来のブロックとフック由来のブロックで文言が別物になる点は、ログを機械集計するときに使えます。Permission to use ... has been denied. なら設定ファイル側、PreToolUse:<Tool> hook error: ならフック側と切り分けられます。
結果2: ガードなし側はモードで結果が割れた
同じ 2 コマンドを、ガードを何も置いていないプロジェクトで実行した結果です。
-
auto:CURL: 200/WGET: GNU Wget 1.21.4 built on linux-gnu.（両方とも実行された） -
manual:CURL: blocked:This command requires approval/WGET: blocked:This Bash command contains multiple operations. The following part requires approval: wget --version -
dontAsk:CURL: blocked:permission_denied
auto mode だけが実際にコマンドを走らせました。manual はヘッドレス実行に承認する相手がいないため停止し、dontAsk は「聞かない代わりに承認が要るものは実行しない」ため停止します。既定モードが manual から auto mode に移るインパクトは、まさにこの列にあります。これまで承認待ちで空振りしていた操作が、8 月 14 日以降は分類器の判断で通るようになります。
結果3: 動かせなかった 2 モード
plan モードでは Bash の実行そのものが拒否され、ExitPlanMode も無効化されていたため、コマンドまで到達しませんでした。
bypassPermissions は起動時点で拒否されました。
--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons
コンテナで root のまま回している環境では、--permission-mode bypassPermissions を指定してもセッションが始まりません。CI イメージの多くが root 実行なので、「危ないから避ける」以前に選べないケースがあります。なお公式リファレンスでは、bypassPermissions を含むすべてのモードで deny ルールと明示的な ask ルールが適用され、逆に allow ルールは bypassPermissions では効果を持たないと明記されています。
共通していたパターン
3 つの結果に共通するのは、モードが決めるのは「何がプロンプトなしで通るか」の下限であり、deny ルールとフックはその上に別レイヤーとして乗る という構造です。実測でも、モードを 4 通り変えてブロックの有無は変わりませんでした。
そのうえで、自動実行の設計に効く注意点が 2 つあります。
1 つ目は、会話で述べた制約は永続しないことです。リファレンスには、分類器が会話中の「push しないで」といった境界を都度読み直して判定する一方、コンテキスト圧縮でその発言が消えると境界も失われると書かれています。恒久的な保証が要るなら deny ルールを使う、と公式が明示しています。
2 つ目は、ヘッドレス実行にはフォールバック先がないことです。auto mode は分類器が 3 回連続または合計 20 回ブロックすると一時停止して通常の承認プロンプトに戻りますが、--permission-prompt-tool を指定しない -p 実行には戻る先のプロンプトがありません。その場合、該当アクションは実行されないまま Claude は作業を続けます（しきい値・挙動の出典はいずれも https://code.claude.com/docs/en/permission-modes ）。ブロックされたことに気付ける仕組みは、自分でログに落とす必要があります。
本プロジェクトでも main への直接 push は PreToolUse フックで物理的に止めています。今回の実測は、その防御が既定モードの変更に影響されないことの裏付けになりました。
8 月 14 日までに確認しておくこと
-
defaultModeを自分で設定しているか（設定済みなら既定は変わらない） - 人間のチェックポイントを残したい操作に
permissions.askルールがあるか - 絶対に通したくない操作が
permissions.denyかフックで二重化されているか（会話中の指示だけに頼らない） - ヘッドレス実行のログから、ブロックされたアクションを後追いできるか
おわりに
auto mode の既定化は「承認プロンプトを前提にした運用」から「ルールとフックを前提にした運用」への切り替え期限です。今回の実測範囲では、deny ルールと PreToolUse フックは実行できた 4 モードすべてで機能しました。逆に言えば、ガードを置いていない操作は 8 月 14 日以降そのまま走ります。棚卸しの締め切りが 2 日後に来ている、と考えるのが安全です。
関連記事
- Claude Code 2.1.200「Manual化」、中身は1行も変わっていなかった
- Claude Code archiveプラグイン、sha256改ざん検知を実機で確認
- Claude Code auto modeを安全に回す — 破壊的コマンドを止める3層防御