Choose a permission mode

一行要約

6つのモードは「確認なしに何が走るか」の一次元で並んでおり、auto mode だけは分類器による審査という別の仕組みで動く。そしてどのモードでも protected paths への書き込みは自動承認されない（bypassPermissions を除く）。

要点

6つのモード

モード	確認なしに走るもの	向く場面
`default`（CLI 表示は Manual）	読み取りのみ	使い始め、機微な作業
`acceptEdits`	読み取り + ファイル編集 + よくあるファイルシステムコマンド（`mkdir`、`touch`、`mv`、`cp` など）	レビューしながら反復する作業
`plan`	読み取り + auto mode が使えるなら分類器が承認したコマンド	変更前のコードベース探索
`auto`	すべて（バックグラウンドの安全チェック付き）	長いタスク、プロンプト疲れの軽減
`dontAsk`	事前承認したツールのみ	ロックダウンした CI とスクリプト
`bypassPermissions`	すべて	隔離されたコンテナと VM でのみ

Writes to a small set of paths are never auto-approved, except in bypassPermissions mode and in interactive terminal sessions in plan mode with bypass permissions available.

ごく一部のパスへの書き込みが自動承認されることはない。例外は bypassPermissions モードと、bypass permissions が使える対話端末の plan mode セッションだけである。

モードは基準線を決めるだけ。 その上に permission rule を重ねる。次の3つはどのモードでも効く（bypassPermissions を含む）。

deny rule と明示的な ask rule
組織が設定したコネクタツールの ask
requiresUserInteraction マーカー

allow rule は bypassPermissions では意味がない（すでに全部承認されているため）。

どのモードで始まるか

端末の新規セッションは、最初に当てはまった1つが採られる:

--permission-mode フラグ、または --dangerously-skip-permissions
設定ファイルの permissions.defaultMode
組み込みの既定

プロジェクト側の設定ファイルには "auto" と "bypassPermissions" を書けない。 .claude/settings.json と .claude/settings.local.json に書いても効かない —— リポジトリが自分に権限を与えられないようにするため。効かないだけでは済まない:

"auto" を書くと、~/.claude/settings.json の defaultMode まで読まれなくなり、組み込みの既定に落ちる
"bypassPermissions" を書くと Manual で始まる
他の値はどの設定ファイルからでも効く

組み込みの既定（上から順に、最初に当てはまった行。v2.1.283 以降はプランとプロバイダで分かれない）:

起動のしかた	組み込みの開始モード
どれかの設定ファイルが `disableAutoMode` を `"disable"` にしている	`default`
`claude -p` と Agent SDK	feature flag を取得するセッションでは `default`。取得しないセッション（third-party provider、テレメトリを切った場合など）では v2.1.285 以降 `auto`、それより前は `default`。組織のポリシーが `auto` の既定を差し止めていれば `default`
端末か VS Code 拡張	v2.1.283 以降は `auto`。それより前の版では、feature flag を取得するセッションの Pro / Max / Team だけ `auto`、他は `default`

v2.1.283 で、プランとプロバイダによる分け方が無くなった。 それまで default で始まっていた Enterprise・Claude Console の API キー・Amazon Bedrock / Google Cloud Agent Platform / Microsoft Foundry / Claude Platform on AWS / サインイン済みの Claude apps gateway も、対話ターミナルと VS Code では auto mode で始まる。Amazon Bedrock / Google Cloud Agent Platform / Microsoft Foundry / サインイン済みの Claude apps gateway で auto mode に対応するのは Sonnet 5 以降 / Opus 4.7 以降 / Fable 系だけで、他のモデルでは Manual で始まる（Anthropic API と Claude Platform on AWS では Opus 4.6 以降 / Sonnet 4.6 以降 / Fable 系）。

インストール直後・アップグレード直後の最初のセッションは、feature flag が届く前に開始モードを決めることがあるので、表と違うモードで始まりうる。

組み込みの auto 既定には版が要る —— macOS / Linux / WSL は v2.1.228 以降、ネイティブ Windows は v2.1.233 以降。それより前は組み込みの既定は Manual
選ばれたのが auto でもセッションで使えなければ Manual で始まる（設定で切られている、モデルが対応しない、Anthropic がサーバ側で一時的に止めている、など）
VS Code 拡張は、プロジェクトの .claude/settings.json / .claude/settings.local.json を開始モードのためには決して読まない
~/.claude/settings.json だけが auto 以外の defaultMode を持っている場合、その設定のまま始まる。 Pro / Max / Team と、feature flag を取得しないセッションでは、Claude Code が一度だけ auto mode に変えるか尋ね、断れば設定はそのまま

モードの切り替え

Shift+Tab で default → acceptEdits → plan を巡回する。ステータスバーの表示:

⏸ manual mode on（グレー）
⏵⏵ accept edits on
⏸ plan mode on
⏵⏵ auto mode on
⏵⏵ don't ask on
⏵⏵ bypass permissions on

巡回に入らないモードがある:

auto — アカウントが要件を満たすと現れる
bypassPermissions — --permission-mode bypassPermissions などで起動した後に現れる。--allow-dangerously-skip-permissions は巡回に加えるが有効化はしない
dontAsk — 巡回には決して現れない。--permission-mode dontAsk で設定する

`acceptEdits` の詳細

自動承認されるファイルシステムコマンド: mkdir、touch、rm、rmdir、mv、cp、sed。LANG=C のような安全な環境変数の前置や、timeout / nice / nohup のようなプロセスラッパー越しでも自動承認される。

ただし作業ディレクトリまたは additionalDirectories の中のパスに限る。 それ以外のパス、protected paths への書き込み、組み込みの読み取り専用セット以外の bash コマンドは依然として確認を求める。

plan mode の詳細

Shift+Tab または単発のプロンプトに /plan を前置して入る
計画中のシェルコマンドの扱い（最初に当てはまったもの）: bypass が使える対話ターミナルセッションなら分類器も確認も無い（それでも確認が出るもの —— 明示的な ask ルールや critical path の削除 —— は下の bypassPermissions の節）→ auto mode が使えて useAutoModeDuringPlan（既定でオン） なら、critical path の削除を除いて分類器が審査する → それ以外は読み取り専用の組み込みセット以外が確認になる（sandbox の auto-allow が有効でも）
Shift+Tab をもう一度押すと、計画を承認せずに抜けられる
Ctrl+G で提案された計画をエディタで開いて直接編集できる
計画を承認するとセッション名が計画の内容から自動命名される（--name や /rename で既に付けていない場合）

承認時の選択肢:

Yes, and use auto mode — 承認して auto mode で開始（auto mode が使えないときは “Yes, auto-accept edits”）
Yes, manually approve edits — 承認して各編集を個別にレビュー
No, keep planning — plan mode に留まり、変更点を伝える

auto mode

A separate classifier model reviews actions before they run, blocking anything that escalates beyond your request, targets unrecognized infrastructure, or appears driven by hostile content Claude read.

別の classifier モデルが実行前に行為を審査し、依頼の範囲を超えて権限を広げるもの、認識されていないインフラを対象とするもの、Claude が読んだ敵対的な内容に駆動されていると見えるものをブロックする。

分類器が信頼するのは、作業ディレクトリと、セッション開始時点で設定されていたリモート。 セッション中に git remote add / git remote set-url で追加・変更されたリモートは信頼されない。

審査をサーバ側でやる構成がある。 分類器に回る行為の審査を、自前の分類器リクエストの代わりにセッションのモデルリクエストの一部としてサーバに依頼する。依頼するセッション:

接続	条件
Anthropic API への直接接続	対話ターミナルセッションと、`-p`・Agent SDK・VS Code 拡張・Desktop アプリのセッションで、プランやアカウント種別を問わない（Anthropic が順次展開する）。対話ターミナルでは Pro / Max / Team は v2.1.271 以降、Enterprise と Claude API は v2.1.278 以降、`-p`・Agent SDK・VS Code 拡張・Desktop アプリは v2.1.281 以降。v2.1.282 以降は、feature flag を取得しないセッション（テレメトリを切った場合など）はどの種類のセッションでも既定で依頼する
クラウドプロバイダ、LLM gateway / proxy	Claude Platform on AWS / Amazon Bedrock / Google Cloud Agent Platform / Microsoft Foundry、`ANTHROPIC_BASE_URL` を gateway / proxy に向けたとき。プランを問わない（v2.1.278 以降）
サインイン済みの Claude apps gateway	v2.1.280 以降

サーバが審査したなら、その判定が決める
サーバがそのセッションを審査しない（審査結果の無い応答、または審査しないという返答。多いのは gateway / proxy が審査の依頼か結果を落とす場合と、プラットフォーム・リージョン・資格情報がまだ対応していない場合）→ Claude Code 自身の分類器リクエストに落ちる。落ちたまま以後続くと、分類器リクエストが課金されるアカウントでは課金の通知が出る
サーバがある行為に判定を返さない（審査結果が届く前に応答が終わった、読めない形で届いた。直接接続ではサーバの検査がタイムアウトした場合も）→ 審査なしで走らせず、拒否する。判定の無い応答が10回続くとターンを止める
サーバに聞かせたくないなら CLAUDE_CODE_AUTO_MODE_SERVER=0（Anthropic API への直接接続では v2.1.281 以降。1 にすると、まだ審査の無いセッションでもサーバ審査をオンにする。ただし CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 も設定していればオンにならない）。CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 を設定して CLAUDE_CODE_AUTO_MODE_SERVER を未設定にした場合も、原則としてサーバに聞かなくなる
分類器が見るのは、ユーザーのメッセージ・読み取り専用でないツール呼び出し・CLAUDE.md の内容。ツールの結果は剥がされるので、ファイルや web ページの敵対的な内容が分類器を直接操作することはない
PostToolUse hook の classifierContext フィールドで、呼び出し結果に注釈を付けられる（分類器はアプリケーション由来の context として読む。v2.1.236 以降）

既定でブロックされるもの（抜粋）:

curl | bash のようなコードのダウンロードと実行
機微データの外部エンドポイントへの送信
本番デプロイとマイグレーション、クラウドストレージの大量削除
IAM やリポジトリ権限の付与、共有インフラの変更
セッション開始前から存在したファイルの不可逆な破壊
force push
git reset --hard、git checkout -- .、git restore .、git clean -fd、git stash drop、git stash clear（未コミットの変更を捨てると推定されるため）
トンネルやリバースシェルを開いてローカルサービスを公開インターネットに晒す
生の認証情報やトークンを transcript やファイルに出力する
--insecure のような安全機構を無効化するフラグ付きの実行
--dangerously-skip-permissions や --no-sandbox で人間の承認もサンドボックスもない自律エージェントループを起動する
/tmp や $TMPDIR のファイルを、具体的なパス名ではなくワイルドカード・glob・経過時間フィルタで削除する
Claude Code 自身の tmux ペインにキーストロークを送って自分のインターフェースを操作する（自分の権限や監督を変更する行為と見なされる）
セキュリティ挙動（認証、アクセス制御、入力検証、サンドボックス）を守るテストやアサーションのコメントアウト・削除・強制通過
~/.claude/projects/ 配下の .jsonl transcript への書き込み（読み取りはブロックされない）
代入がどこにも見えないシェル変数を対象とする rm -rf "$VAR"（値がコマンド出力由来で、分類器には検証できないため）

ブロックが厳しすぎるときは、管理者が autoMode.environment に信頼するリポジトリ・バケット・サービスを書く（claude auto-mode defaults で既定のルール一覧が JSON で出る）。コンテナやノードのような「Host containment」の話も同じ設定に書く。

既定で許可されるもの:

作業ディレクトリ内のローカルファイル操作
lock ファイルや manifest に宣言済みの依存関係のインストール
.env を読んで、対応する API に認証情報を送ること
読み取り専用の HTTP リクエスト
作業中のリポジトリの任意のブランチへの push（デフォルトブランチを含む）と、依頼に沿った pull request の作成。ただし production や gh-pages のようにデプロイ / 公開先と分かる名前のブランチ、別リポジトリ / 別組織を対象にする pull request は別途判断される。人間の確認を挟みたいなら permissions.ask ルールを書く（コマンドは書かれたとおりに照合される）
エージェント同士のメッセージ
environment に列挙した信頼済みドメイン・バケット・サービスへのデータ送信

sandbox で走るコマンドには既定でネットワークが無い。 必要なホストは Claude がコマンドに添えて申告し、分類器がコマンドと一緒に審査して、承認された一覧はそのコマンド1回だけそのホストを開く。

会話で述べた境界

The classifier treats boundaries you state in the conversation as a block signal. If you tell Claude “don’t push” or “wait until I review before deploying”, the classifier blocks matching actions even when the default rules would allow them. A boundary stays in force until you lift it in a later message. Claude’s own judgment that a condition was met does not lift it.

classifier は、会話の中であなたが述べた境界をブロックの信号として扱う。「push するな」「レビューするまでデプロイを待て」と Claude に伝えると、classifier は該当する動作を、既定のルールなら許可する場合であってもブロックする。この境界は、後のメッセージであなたが解除するまで効力を持ち続ける。条件が満たされたという Claude 自身の判断では解除されない。

ただし境界はルールとして保存されない。 分類器は毎回 transcript から読み直すので、context compaction でその発言が消えると境界も失われる。確実にしたいなら deny rule を書く。

auto mode のフォールバック

連続3回、または合計20回ブロックされると auto mode が一時停止し、確認プロンプトに戻る。この閾値は設定できない。 合計カウンタはセッション中持続し、自分の上限で確認に戻ったときだけリセットされる。

--permission-prompt-tool の無い -p では戻る先の確認が無いので、閾値に達してもその操作は走らず、Claude は作業を続ける。run は止まらない。

拒否された操作は /permissions の Recently denied タブに出て、r を押すと手動承認でリトライできる。

`dontAsk`

確認を求めるはずのツール呼び出しをすべて自動拒否する。走るのは permissions.allow にマッチするもの、読み取り専用 bash コマンド、PreToolUse hook が承認したもののみ。AskUserQuestion も拒否される。

`bypassPermissions`

bypassPermissions offers no protection against prompt injection or unintended actions.

bypassPermissions は、prompt injection や意図しない動作に対して何の防御にもならない。

それでも確認が出るもの:

明示的な ask rule、組織が ask にしたコネクタツール、requiresUserInteraction の MCP ツール
rm -rf / と rm -rf ~ のような critical path の削除（モデルのエラーに対する circuit breaker。下の「critical paths」）。ターミナルでは2分の時間制限つき
cross-session messaging の isolatePeerMachines 承認

制約:

有効化せずに始めたセッションから途中で入ることはできない
初回は責任を引き受ける警告ダイアログが出る（断ると Claude Code は終了する）。受け入れると ~/.claude/settings.json に skipDangerousModePermissionPrompt: true が書かれ、以後は出ない（もう一度出したいならこのキーを消すか false にする）
Linux / macOS で root や sudo の下では起動を拒否する（認識されたサンドボックス内ではスキップされる）
Claude Code on the web は設定ファイルの bypassPermissions / dontAsk を honor しない（リポジトリにコミットされた設定でクラウドセッションを bypass にできないようにするため）

protected paths

モード	protected path への書き込み
`default`, `acceptEdits`	確認
`plan`	対話端末で bypass が使えるセッションなら許可。そうでなければ、計画中に auto mode が使えるなら分類器へ、使えないなら確認
`auto`	分類器へ
`dontAsk`	拒否
`bypassPermissions`	許可

permissions.allow rules in settings files do not pre-approve protected-path writes. The safety check runs before Claude Code evaluates allow rules from settings, so an entry such as Edit(.claude/**) in ~/.claude/settings.json or .claude/settings.json does not change the per-mode outcome in the table above.

設定ファイル内の permissions.allow ルールは、保護されたパスへの書き込みを事前承認しない。安全性のチェックは、Claude Code が設定の allow ルールを評価する前に走るので、~/.claude/settings.json や .claude/settings.json に Edit(.claude/**) と書いても、上の表のモードごとの結果は変わらない。

--restricted で始めたセッションでは、分類器も protected path への書き込みを承認できない（v2.1.248 以降）
確認が出るモードでは、プロジェクトの .claude/ と ~/.claude/ への書き込みのプロンプトに、そのセッション限りで以後の書き込みを通す選択肢が出る（「Yes, and allow Claude to edit files in this project’s .claude folder for this session」/「…in its ~/.claude folder for this session」）
symlink の検査が解決した先が protected path なら、Claude が要求したパス自体が protected でなくても、分類器に回すモードでは確認が出る

保護ディレクトリ: .git, .config/git, .vscode, .idea, .husky, .cargo, .devcontainer, .yarn, .mvn, .claude（.claude/worktrees と、--restricted なしで始めたセッションでの auto memory ディレクトリの markdown は除く）、--plugin-dir で読み込んだディレクトリ（ファイルが変わると mod のコードを読み直して走らせるため）

保護ファイル: .gitconfig, .gitmodules / シェル起動ファイル各種（.bashrc, .zshrc, .profile, .envrc ほか）/ パッケージマネージャ設定（.npmrc, .yarnrc, bunfig.toml ほか）/ .bazelrc 系 / .pre-commit-config.yaml, lefthook.* / gradle-wrapper.properties, maven-wrapper.properties / .devcontainer.json / .ripgreprc, pyrightconfig.json / .mcp.json, .claude.json

critical paths —— allow を上書きする回路遮断器

protected paths とは別の仕組み。rm / rmdir が critical path を狙ったときは、permissions.allow も PreToolUse hook の "allow" も通らない。

Claude Code never lets a permissions.allow rule or a PreToolUse hook that returns "allow" approve an rm or rmdir command that targets a critical path, even in modes that skip other prompts. This circuit breaker guards against model error.

Claude Code は、critical path を狙う rm / rmdir を、permissions.allow ルールにも "allow" を返す PreToolUse hook にも承認させない。他の確認を飛ばすモードにいてもそうである。この回路遮断器はモデルの誤りに備えるもの。

モードごとの挙動が直感に反する。

モード	critical path の削除
`default` / `acceptEdits`	確認を求める
`plan`	確認を求める（計画中に分類器が審査していて bypass が使えない場合は `auto` と同じ扱い）
`auto`	ターミナルでは時間制限つきで確認を求める。それ以外では拒否
`dontAsk`	拒否
`bypassPermissions`	確認を求める（飛ばさない。ターミナルでは時間制限つき）

以前の取得で auto の扱いが「分類器へ送る」から変わった（auto と bypassPermissions の扱いは v2.1.281 以降）。明示的な ask ルールに当たれば、auto でも時間制限なしで確認になる。時間制限はターミナルで2分:

答えないまま時間切れになると、Claude Code はコマンドを拒否し、代わりに何をすべきかを Claude に伝える —— 無人のセッションでも作業が止まらない
プロンプトが開いている間に何かキーを押すと、カウントダウンが止まり答えを待ち続ける
1セッションで3回時間切れになると、以後は確認を出さず即座に拒否する（新しいメッセージを送ると数え直し）
auto でターミナルの確認を出せない場所（-p、Agent SDK、VS Code 拡張のチャットパネル、Desktop アプリ）では即座に拒否し、消したかったものを報告して削除はあなたに任せるよう Claude に伝える
CLAUDE_CODE_DISABLE_DANGEROUS_RM_TIMEOUT=1 で元に戻せる（auto では分類器へ、bypassPermissions では時間制限なしの確認）

critical path の範囲: ファイルシステムのルート / ルート直下のディレクトリ（/usr /etc など）/ ホームディレクトリ / Windows のドライブルートとその直下（C:\ C:\Windows）/ 作業ディレクトリとその親 / 追加の作業ディレクトリとその親（ただし rm -rf <dir>/* のような glob のときだけ。rm -rf <dir> 自身は該当しない）。

変数を使った書き方も拾う。

Claude Code also treats a glob or trailing slash directly under a shell variable, such as rm -rf "$DIR"/*, as a critical-path removal, because the command becomes a removal from the filesystem root when the variable is empty.

シェル変数の直下の glob や末尾スラッシュ（rm -rf "$DIR"/* など）も critical path の削除として扱う。変数が空のとき、そのコマンドはファイルシステムのルートからの削除になるため。

$(...) やバッククォート、<(...) に隠しても回避できない。echo "$(rm -rf ~)" のように置換の中にあっても見つける。

以前の取得で、critical path とみなす対象が増えた:

シェル変数の後にトップレベルのディレクトリ名が1つ（rm -rf "$TMPDIR/mnt"）—— 変数が空だと /mnt を消す。mnt tmp usr Users のような名前が対象
同じコマンドがディレクトリを出力する置換から代入した変数（D=$(pwd); rm -rf "$D"、$(git rev-parse --show-toplevel) から代入）—— 作業ディレクトリやリポジトリのルートを指しうる。変数は空ではないので "${D:?}" のガードでは通らない。リテラルのパスを使う
バックスラッシュだけの対象（rm -rf "\\"）—— Git Bash on Windows では現在のドライブのルートになるので、全プラットフォームで検査する
対象がコマンド置換の出力だけ（rm -rf "$(pwd)"。再帰の rm のとき）—— 実行前に対象を確かめられないので、置換を先に単独で走らせ、出力されたリテラルのパスを消すよう Claude に伝える（この検査だけ CLAUDE_CODE_DISABLE_SUBSTITUTION_RM_PROMPT=1 で切れる）
末尾のコマンド置換が空に展開しうるとき（rm -rf ~/$(cmd)）は、残るパス（この例ではホーム）で判定する

以前の取得でさらに増えた（原典は対象を表にまとめ直し、書き直し方の節を独立させた）:

位置パラメータの直下の glob や末尾スラッシュ（rm -rf "$1"/*。$1 や $@ にコマンド内で値が与えられていないとき）—— ルートからの削除に展開される
/* や /*/ で終わる一部の対象（rm -rf logs/*/*、rm -rf logs/*/、cd logs && rm -rf a/*）—— どのディレクトリに届くか実行前に分からない
-c で渡したインラインスクリプトの中も見る（bash -c 'rm -rf ~'）。ダブルクォートのスクリプトは外側のシェルが変数を展開してから内側に渡すので、find . -name '*.tmp' -exec sh -c "rm -rf \"$1\"/*" _ {} \; はマッチごとにルートからの削除になる。シングルクォートで $1 に実際の値を束ねる sh -c 'rm -rf "$1"/*' _ {} は引っかからない。スクリプトに直接書いた critical path の検査だけ CLAUDE_CODE_DISABLE_INLINE_SHELL_RM_PROMPT=1 で切れる（起動する環境に置く）

PowerShell の Remove-Item と、cmd の組み込み rd / rmdir / del / erase は別系統の検査（PowerShell tool を有効にした場合）。cmd /c rd /s /q C:\Users のように cmd 経由でシステムパスを消すコマンドも、既定でどのモードでも確認なしに拒否される（v2.1.283 以降。リテラルの後に続く PowerShell 変数は空とみなすので "C:\$name" は C:\ の削除として拒否。末尾のワイルドカードはそのフォルダを空にするものとして数える。CLAUDE_CODE_DISABLE_POWERSHELL_CMD_RM_DENY=1 で切れるが、settings の env ブロックでは無視される。Remove-Item のシステムパス拒否はどちらでも残る）。Remove-Item では、システムパスとワイルドカード（*、/*、\*、$dir/*）は、どのモードでも確認なしに拒否され、classifier にも渡らない。作業ディレクトリとその親への -Recurse は通常の承認扱い（bypassPermissions はこの検査だけ飛ばす）。

そのまま使える具体例

起動時にモードを指定する:

claude --permission-mode plan
claude --permission-mode acceptEdits
claude --permission-mode dontAsk
claude --permission-mode bypassPermissions   # == --dangerously-skip-permissions

プロジェクトの既定を plan にする（.claude/settings.json）:

{
  "permissions": {
    "defaultMode": "plan"
  }
}

auto を既定にするなら ~/.claude/settings.json に置く（リポジトリが自分に auto mode を付与できないようにするため、.claude/settings.json と .claude/settings.local.json からは無視される。しかも書いてあると ~/.claude/settings.json の defaultMode まで読まれなくなり、組み込みの既定に落ちる —— 上の「どのモードで始まるか」）:

{
  "permissions": {
    "defaultMode": "auto"
  }
}

分類器の既定ルール全文を見る:

claude auto-mode defaults

組織として無効化する（managed settings）:

{
  "permissions": {
    "disableAutoMode": "disable",
    "disableBypassPermissionsMode": "disable"
  }
}

会話で境界を宣言する（分類器がブロック信号として扱う）:

don't push
wait until I review before deploying

原典で言及されている関連文書

mods-overview — tool.check を扱う mod は分類器より前に承認できる
claude-code-auto-mode — 分類器の内部設計と実測値
how-claude-code-works — permission mode の概観と checkpoint
claude-code-sandboxing — sandbox によるもう一方のアプローチ
how-we-contain-claude — 環境層での封じ込め
sub-agents — subagent の permissionMode と親の優先
permissions — permission rule の構文
settings — 設定ファイル

ai-docs

エクスプローラー

Choose a permission mode

一行要約

要点

6つのモード

どのモードで始まるか

モードの切り替え

`acceptEdits` の詳細

plan mode の詳細

auto mode

会話で述べた境界

auto mode のフォールバック

`dontAsk`

`bypassPermissions`

protected paths

critical paths —— allow を上書きする回路遮断器

そのまま使える具体例

原典で言及されている関連文書

目次

バックリンク

ai-docs

エクスプローラー

Choose a permission mode

一行要約

要点

6つのモード

どのモードで始まるか

モードの切り替え

acceptEdits の詳細

plan mode の詳細

auto mode

会話で述べた境界

auto mode のフォールバック

dontAsk

bypassPermissions

protected paths

critical paths —— allow を上書きする回路遮断器

そのまま使える具体例

原典で言及されている関連文書

目次

バックリンク

`acceptEdits` の詳細

`dontAsk`

`bypassPermissions`