パーミッションモードとは、エージェントがツールをどう使うかをグローバルに制御する、セッション全体の設定である。Claude Agent SDK のドキュメントでは、これは固定された評価順序の中で特定の位置を占めている。フック、deny ルール、ask ルールが参照された後、allow ルールとランタイムコールバックの前である。この位置こそが、この概念に正確な意味を与えている。つまりモードは、それより前のステップで決着しなかったリクエストに対する基本的な扱いを決めるものである。
その位置がこの考え方の本質である。deny ルールと ask ルールはモードが適用される前に評価されるため、ドキュメントは、最も寛容なモードであっても両者は引き続き効力を持つと述べている。したがってモードは、デフォルトを引き上げたり引き下げたりはするが、その周囲に宣言された制御を取り除きはしない。
用法
文書化されているモードは六つある。default はモードに基づく自動承認を何も加えないため、承認が必要でどの allow ルールにも一致しない呼び出しはコールバックに到達する。dontAsk は、本来なら確認を求めることになるものをすべて拒否し、コールバックを一切呼び出さないが、ルールによって承認された呼び出しと承認を必要としない呼び出しは引き続き実行する。acceptEdits はファイル編集とファイルシステム操作を自動承認し、その他のツールは通常の処理に委ねる。bypassPermissions は、どのモードでも自動承認されない文書化された一連の操作を除き、確認なしでツールを実行する。plan はファイル編集が自動承認されないようにし、エージェントがソースファイルを編集せずに調査と計画を行えるようにする。auto は判断をモデルの分類器に委ねる。
モードはクエリの作成時に設定することも、セッション中に変更することもでき、ドキュメントは、制限的な状態から始めて信頼が築かれるにつれて緩めるという使い方を提案している。サブエージェントについては親セッションから継承されるが、文書化された例外として、最も寛容なモードは、親自身がそのモードで実行されていない限りサブエージェントには決して適用されない。その理由として述べられているのは、サブエージェントは異なるシステムプロンプトとより制約の少ない振る舞いを持つ可能性があり、そのモードを継承させるとシステムへの完全な自律的アクセスを与えることになる、というものである。
SDK のドキュメントがモードを対等な選択肢のリストとして提示しているのに対し、Claude Code のベストプラクティスのドキュメントは、セッションが実際にどのモードで開始されるかを説明しており、それをユーザーの選択ではなくプランに依存するデフォルトとして扱っている。Pro、Max、Team プランでは、対話型のターミナルと VS Code のセッションにおける組み込みの開始モードは auto モード であり、それ以外のプランでは Manual モード である。両者は、誰がレビューを行うかによって特徴づけられる。Manual モードでは、エージェントはシステムを変更しうるあらゆること、すなわちファイルの書き込み、Bash コマンド、MCP ツールの前に確認を求める。ドキュメント自身がこれを安全だが面倒だと呼び、10 回目の承認のころにはユーザーはレビューするのではなくクリックして通過させているだけになると述べている（承認疲れ（Approval Fatigue） を参照）。auto モードでは、ユーザーに代わって別の分類器モデルがほとんどのアクションをレビューし、リスクがあると見えるものだけをブロックする。挙げられているカテゴリはスコープの拡大、未知のインフラストラクチャ、敵対的なコンテンツに駆動されたアクションの三つである。
Manual モードでの中断を減らしつつ、auto モードでも同様に適用されるものとして、二つの手段が文書化されている。安全であるとわかっている特定のツールを事前承認するパーミッションの許可リストと、ファイルシステムとネットワークの OS レベルの分離を有効にし、定められた境界内でエージェントがより自由に作業できるようにする サンドボックス化 である。同じドキュメントは、分類器モードの対話的な使用と非対話的な使用の間の振る舞いの違いにも触れている。非対話的な実行の中で分類器がアクションを繰り返しブロックした場合、実行は停止されず、代わりに文書化されたフォールバックが適用される。
分類器モードの仕組み（作り手の説明による）
Claude Code チームの二人のメンバーが、対談の中で auto モードについてより踏み込んだメンタルモデルを示しており、それが Claude Code チームの Cat と Thariq とのファイアサイドチャット で伝えられている。彼らの説明によれば、分類器は Sonnet モデルであり、それが判断するのはツール呼び出し単体ではなく、ユーザー自身の指示を含む会話のコンテキストとあわせた呼び出しである。彼らはこれを、このモードに特有の性質、すなわちリクエストに依存するパーミッションとして提示している。彼らの例は、コーディングエージェントにリモートへの push を常時許可することはしないだろうが、「これを GitHub に push して」と言えばそれは許可されるべきであり、「push しないで」と言えば拒否されるべきだ、というものである。そして後者のケースは実際によく起こると報告している。エージェントが役に立とうとして何かを提案し、ユーザーがそれを禁じていたためにモードがそれを取り上げる、という場面である。
彼らはまた、このモードを OS レベルの分離と重複するものではなく、それを補完するものとして説明している。彼らによれば、サンドボックス化にはエッジケースが非常に多く、それらに決定論的に従うことは難しい。そのため、何かがサンドボックスから外に出る必要があるとき（例として挙げられているのはネットワークリクエスト）、分類器はそのリクエストを検査し、許可する前にそれが理にかなっているかどうかを判断できる。より一般的には、このモードは、本来ならユーザーが目にしたはずのあらゆるパーミッションの確認と相互に作用すると、そのうちの一人は述べている。同じ議論の中で、隣接する二つの仕組みにも言及がある。リモートコントロールのユーザー向けの信頼済みデバイスと、クレデンシャルインジェクションである。後者では、プロキシがエージェントの送信リクエストにクレデンシャルを挿入するため、エージェントはそれを使えるが、それにアクセスすることはできない。
適用される場面
この概念が当てはまるのは、ツールのパーミッションがモデルの外で評価されるハーネスであり、ルールの体系が併存していることを前提とする。モード単体が表すのは姿勢だけであって、ポリシーではない。ドキュメントはこの区別を、明示的な allow リストと dontAsk を組み合わせたロックダウン構成で説明している。これにより、リストにあるツールは実行され、それ以外の確認を求める呼び出しはすべて拒否される。
文書化されている誤用は、モードをデフォルトではなく制約として扱うことである。allow リストは bypassPermissions を狭めない。リストにないツールはどの allow ルールにも一致せず、モード自体によって承認されるからである。ツールを手の届かないところに置くには、代わりに deny ルールを使うようドキュメントは指示している。
実務者による説明は、同じトレードオフの反対側にある第二の誤用を付け加えている。2026年のAI Coding Agent活用 ── スピードと安全性を両立させる は、まず allow リストと deny リストを整備し、そのうえで編集を自動承認するモードで作業することを推奨しており、その際にどちらに寄せて誤るべきかについても具体的である。問題のない操作は、確認を求めさせたままにするのではなく、積極的に allow リストに入れるべきだという。その理由は、確認を求めすぎる構成は自らを無力化するからである。人々は何を承認しているのかを読まずに承認し始め、最も慎重に見える姿勢が実際にはセキュリティを低下させる（承認疲れ（Approval Fatigue） を参照）。同じ投稿は、人間による承認を完全にオフにして実行することは商用開発には不適切だとし、著者自身は隔離されたコンテナ内でのオープンソースの作業に限ってそれを使っていると報告している。エージェントが サンドボックス化 のもとで動いている場合には、シェルコマンドをサンドボックス化されているがゆえに自動許可する設定を、チェックを取り除かずに確認の回数を減らす方法として挙げている。
どの程度確立されたものか。これは一つのベンダーが自社の SDK と自社のコーディングツールのために文書化した設計であり、上記のモード名は業界全体の標準ではなく、そのベンダーの用語である。二つ目のソースは、それとは別種の注意点を加えている。そこではセッションがどのモードで開始されるかがユーザーのサブスクリプションプランに結びついており、したがって開始時の姿勢は安全上の判断であると同時に商業上の判断でもある。
分類器モードについての最も強い主張は、ドキュメントではなく上で引用した対談の中でベンダー自身のチームが行ったものであり、インタビュアーはそのうちの一つにその場で異議を唱えた。彼らは、社内のほぼ全員が auto モードを使っていると報告し、それを Claude Code で長時間の作業を安全に行う最良の方法だと呼んでいる。何千もの評価、社内の全ユーザーにわたって実施された評価、そしてプロンプトインジェクションや悪意のある入力を含む敵対的な環境を構築する複数の委託レッドチームを挙げ、それらのチームが見つけたすべての問題は緩和済みだと述べている。より強い言い方は明確に退けており、100% を捕捉するわけではない、それはあまりにも強すぎる主張だと述べたうえで、比較を相対的なものとして提示している。彼らが重視するリスクのカテゴリ、特に プロンプトインジェクション とデータの持ち出しについて、リスクは平均的な人間のレビュアーよりもはるかに低いと主張している。裏付けとなる評価は公開される予定だと彼らは述べたが、その対談が伝えられた時点では公開されておらず、したがってこれらの数字の根拠はここからは独立に確認できない。出所についてもう一点補足すると、彼らは社内での使用を 1 月、つまり一般に公開されるよりかなり前としており、このモードを、Slack に常駐する彼らのエージェント Claude Tag をそもそも成り立たせる基盤として挙げている。誰でも投稿できるチャンネルを読むエージェントは、その構造上プロンプトインジェクションにさらされるからである。
関連用語
- Claude Agent SDK — これらのモードを定義しているドキュメントの SDK
- 拒否優先のパーミッション評価 — この評価順序が表している安全上の姿勢
- ヒューマン・イン・ザ・ループ — 確認を求めるモードが最終的に頼るもの
- エージェントフック — モードより前に評価され、どのモードでも拒否できるステップ
- 承認疲れ（Approval Fatigue） — これらのモードとトレードオフの関係にある人間側のコスト