Claude Code の開始モードは auto が既定、権限モード 6 種類と defaultMode の設定
v2.1.283 以降、ターミナルと VS Code のセッションはプランを問わず auto モードで始まります。6 つの権限モードの違いと、プロジェクト設定では効かない defaultMode の 2 つの値を整理します。
目次
Claude Code の permissions.defaultMode は、「allow にも deny にも一致しなかった操作をどう扱うか」を決める設定です。指定できる値は 6 つあります。
結論として、個人開発なら acceptEdits、初めて触るコードベースや設計作業なら plan、CI で許可リストを厳密にするなら dontAsk、隔離環境だけ bypassPermissions が目安です。
KEY POINT
この記事で分かること
- 6 つのモードの違い(何が自動で、何が確認されるか)
- セッションの開始モードが決まる順序
- プロジェクト設定では効かない 2 つの値
6 つの値の比較
| 値 | 確認なしで実行されるもの | 向いている場面 |
|---|---|---|
default | 読み取りのみ | すべての操作を自分で確認したいとき、慎重な作業 |
acceptEdits | 読み取り、ファイル編集、mkdir・touch・mv・cp などの一般的なファイル操作 | 自分でレビューしながらコードを回すとき |
plan | 読み取りと、auto モードが使える場合は分類器が承認したコマンド | 変更前にコードベースを調べるとき |
auto | すべて(バックグラウンドの安全チェック付き) | 長い作業、確認疲れの軽減 |
dontAsk | 読み取りと事前承認済みのツール。確認が必要なものは拒否される | 権限を絞った CI やスクリプト |
bypassPermissions | すべて | 隔離されたコンテナや VM のみ |
すべての操作を確認するモードは、CLI や各拡張、デスクトップアプリで Manual と表示されます。設定値は default で、CLI は manual も別名として受け付けます(v2.1.200 以降)。
モードが決めるのは土台だけです。deny に一致する操作は bypassPermissions を含むすべてのモードでブロックされ、allow ルールは bypassPermissions では効果がありません。defaultMode が効くのは、どのルールにも一致しなかった操作です。
セッションの開始モードが決まる順序
Claude Code v2.1.283 以降、ターミナルと VS Code 拡張のセッションは、プランを問わず組み込みの開始モードが auto になりました。それより前のバージョンでは、auto が組み込みの既定値になるのは Pro・Max・Team プランだけです。
ターミナルで新しいセッションを始めるとき、モードは次のうち最初に該当したもので決まります。
--permission-modeフラグ、または--dangerously-skip-permissions- 設定ファイルの
permissions.defaultMode - 組み込みの既定値
プロジェクト設定では効かない値が 2 つある
.claude/settings.json と .claude/settings.local.json に "auto" を書いても効きません。しかもその場合、~/.claude/settings.json の defaultMode ではなく組み込みの既定値が使われます。同じ 2 つのファイルに "bypassPermissions" を書いた場合も効かず、セッションは Manual モードで始まります。他の値はどの設定ファイルからでも適用されます。なお公式の設定ドキュメントは、v2.1.257 より前は bypassPermissions がどの設定ファイルからでも効いていたとも書いています。
設定の書き方
{
"permissions": {
"defaultMode": "acceptEdits"
}
}
ユーザー全体の既定にするなら ~/.claude/settings.json、プロジェクトごとなら .claude/settings.json、自分だけなら .claude/settings.local.json に書きます。
用途別の選び方
個人開発:acceptEdits
ファイル編集を毎回確認する手間がなくなり、コマンド実行(テスト、インストール、Git)は確認できます。編集内容は後から git diff でまとめて見る運用にすると効率的です。
初めてのコードベース・設計作業:plan
変更を伴わないので、安心して調査と計画を任せられます。計画に納得してから acceptEdits に切り替えて実装に進みます(Plan Mode の使い方)。
チーム共有の設定:default か acceptEdits
プロジェクトの settings.json に書く場合は、慎重な側に倒しておきます。速く進めたい人は自分の settings.local.json で acceptEdits に上書きできます。
CI・使い捨てコンテナ:dontAsk か bypassPermissions
確認する人がいない環境では、確認待ちで止まらないようにします。許可リストを厳密に決めて動かすなら dontAsk が向いています(確認が必要な操作は拒否されます)。すべてを通す bypassPermissions は、Claude Code が壊せないよう隔離された環境だけで使ってください。詳しい条件は bypassPermissions を安全に使える条件 にまとめています。
bypassPermissions でも deny は有効
bypassPermissions でも deny ルールはブロックします(逆に allow ルールは効果がありません)。CI で使う場合でも、rm -rf や force push の deny は入れておいてください。
一時的に切り替える方法
| 方法 | 範囲 |
|---|---|
Shift+Tab | 現在のセッション内。利用できるモードを順に切り替える |
claude --permission-mode plan | そのセッションの初期モード |
claude -p ... --permission-mode acceptEdits | 非対話モードの 1 回の実行 |
いずれも設定ファイルは書き換えません。「普段は acceptEdits、今日は調査だけ」のような使い分けは、設定を変えずに Shift+Tab や起動オプションで行います。
関連する設定
defaultMode だけでは「どのコマンドを自動にするか」は決められません。allow / ask / deny と組み合わせた全体の設計は、親記事の settings.json で permissions を設計する を参照してください。
まとめ
- モードは 6 種類。
default(Manual)・acceptEdits・plan・auto・dontAsk・bypassPermissions - deny はすべてのモードで効き、allow は
bypassPermissionsでは効果がない - v2.1.283 以降、ターミナルと VS Code の開始モードはプランを問わず auto。フラグ →
defaultMode→ 組み込みの既定値の順で決まる autoとbypassPermissionsは.claude/settings.jsonと.claude/settings.local.jsonでは効かないShift+Tabと--permission-modeは一時的な切り替えで、設定ファイルは変わらない
よくある質問
- セッションはどのモードで始まりますか?
- Claude Code v2.1.283 以降、ターミナルと VS Code のセッションはプランを問わず組み込みの開始モードが auto です。それより前のバージョンでは Pro・Max・Team プランだけが auto でした。--permission-mode フラグが最優先で、次に設定ファイルの permissions.defaultMode、最後に組み込みの既定値の順で決まります。
- defaultMode は公式ドキュメントのどこに書かれていますか?
- キー自体の説明は設定リファレンスの permissions.defaultMode の項目にあり、プロジェクト設定で効かない件は設定ページのトラブルシューティングに書かれています。v2.1.257 より前は bypassPermissions がどの設定ファイルからでも効いていました。
- defaultMode を .claude/settings.json に書いたのに効きません。
- auto と bypassPermissions は .claude/settings.json と .claude/settings.local.json では効きません。bypassPermissions を書いた場合はセッションが Manual モードで始まります。他の値はどの設定ファイルからでも適用されます。
- acceptEdits にするとコマンドも自動実行されますか?
- されません。acceptEdits が自動で通すのは読み取り・ファイル編集と、mkdir・touch・mv・cp のような一般的なファイルシステム操作です。それ以外は引き続き確認(または allow ルール)に従います。
読者からの質問と回答
Q. auto モードが、プロジェクトのコンテキストファイルを読むような無害な操作までブロックします。読み取りは分類器を通らないはずではないのですか。
公式ドキュメントの「How the classifier evaluates actions」には、auto モードでの判定が先に一致したものが勝つ 4 段階として書かれています。読み取りが止まる原因は、この順序のどこに当たっているかで切り分けられます。
段階 2 が基本の挙動です。「Read-only actions and file edits in your working directory are auto-approved」とあり、作業ディレクトリ内の読み取りは分類器に行かずに自動承認されます。つまり、それでもブロックされているなら例外のどれかに当たっています。
考えられる原因を、起きやすい順に挙げます。
- サーバー側の分類器レビューが効いている: 同じ段階 2 の例外として「In a session with server-side classifier review, read-only and sandboxed shell commands wait for that review and are blocked if it flags them」と書かれています。読み取り専用のコマンドが待たされ、フラグが立てばブロックされる、というのはここだけに書かれた挙動です
- 作業ディレクトリの外にある: 「the first read outside the working directories」は確認のプロンプトが出ます。コンテキストファイルがリポジトリの外にあると該当します。
/add-dirか設定のadditionalDirectoriesで作業ディレクトリに加えると変わります - deny ルールに一致している: 段階 1 で即座に解決します。deny はどのモードでもブロックします
- ネットワークパス(UNC)からの読み取り: allow ルールがあっても確認のプロンプトが出ます
auto モードに入ると一部の allow ルールが落とされる
「以前は通っていたのに auto モードだと止まる」場合はこちらです。公式ドキュメントによると、auto モードに入る時点で、任意のコード実行を許す広い allow ルールが落とされます。対象は Bash(*) や PowerShell(*) のような全体指定、Bash(python*) のようなワイルドカード付きインタプリタ、パッケージマネージャの run コマンド、Agent の allow ルール、Monitor の allow ルールです。Bash(npm test) のような狭いルールは残ります。auto モードを抜けると復元されます。
ブロックされた理由の見方も決まっています。「If the classifier blocks, Claude receives the reason. In most sessions the reason names the rule the classifier matched, such as [Data Exfiltration], rather than giving a written explanation」とあり、多くの場合は文章ではなく一致したルール名が返ります。
モードごとの違いは Claude Code の権限モード にまとめてあります。
Q. auto モードで git の履歴書き換えコマンドが [Git Destructive] として拒否されました。チャットで「はい」と答えても同じ拒否が返ります。承認する方法はないのですか?
承認する方法はあります。公式の auto モード設定ドキュメントに 4 通り載っています。
まず、チャットで「はい」と答えても通らない理由です。ドキュメントによると、分類器の soft_deny を上書きできる「明示的な意図」とは、ユーザーのメッセージが、Claude がこれから取る操作そのものを直接かつ具体的に述べている場合です。一般的な依頼は該当しません。「リポジトリを整理して」は force push を許可しませんが、「このブランチを force push して」は許可します。単なる「はい」は、操作を具体的に述べていないので意図として扱われません。
手段は次のとおりです。
| やりたいこと | 方法 |
|---|---|
| 今後この種の操作を確認なしで通す | autoMode.allow に散文でルールを追加する(soft_deny の例外として働く) |
| 今回だけ通す | 次のメッセージで操作を具体的に書いて再試行させる |
| 拒否された呼び出しを拾い直す | /permissions の Recently denied タブで対象を選び r を押す。ダイアログを閉じると再試行が許可される |
| 設定ファイルを開かずに追加する | /permissions の Auto mode タブ(v2.1.246 以降) |
autoMode.allow は ~/.claude/settings.json に書きます。プロジェクトの .claude/settings.json と .claude/settings.local.json からは読まれません。リポジトリに置いたファイルが自前の許可ルールを注入できないようにするためです。既定のルールを残したまま追加するには、配列に "$defaults" を含めます。
{
"autoMode": {
"allow": [
"$defaults",
"未 push のコミットに対する git commit --amend --reset-author は許可する: 著者情報の修正のみで、公開済み履歴は書き換えない"
]
}
}
拒否された Git Destructive ルールの全文は claude auto-mode defaults --label 'Git Destructive' で読めます(v2.1.208 以降)。このルールには「ユーザーが amend / reword / fixup を依頼した場合は解除される」という条件も含まれているため、依頼の書き方だけで通ることもあります。
参考にした一次情報
この記事は公式ドキュメントを基に AI が下書きを作成し、運営者が内容を確認して公開しています。誤りを見つけた場合は お問い合わせからお知らせください。