Claude Code、新セッションで自動モードをデフォルトに
本文の状態
日本語全文を表示中
詳細モードで約22分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
TLDR AI
Anthropic は Claude Code のデフォルト動作を「自動モード」に変更し、安全性の検証結果に基づきプロ・チームプランでも追加料金を廃止すると発表した。
Continue in AI NEW LAB
このニュースを、実務の判断につなげる
AI NEW LABで、試したことや先に確認したい条件を共有できます。まずはログインなしで読めます。
AI NEW LABで論点を見るAI深層分析を開く2026年8月11日 22:31
AI深層分析
キーポイント
デフォルト設定の変更と料金廃止
8月14日以降、Pro、Max、Team プランの新セッションで自動モードがデフォルトとなり、分類器のオーバーヘッド料金が無料化される。
安全性の実証データ
内部レッドチームや 1,053 名の有料テスターによる制御試験など複数の検証で、自動モードは手動レビューに匹敵または上回る安全性を示した。
エントプライズ・API 版の対応
Claude Enterprise や API、主要クラウドプラットフォームでは現時点でオプトインだが、今後デフォルト化され管理設定による変更が可能となる。
生産性向上の実績
Adobe などの企業事例において自動モード利用者はプルリクエストの提出数が約 25% 増加しており、長時間実行タスクの実用性が向上した。
自動承認モードの安全性は手動レビューを上回る
1,053名のテスト環境における実験では、人間の承認が危険なコマンドを検出できたのは13.6%に過ぎなかった一方、自動モードは89%を検出した。
重要な引用
On every measure we tested, auto mode matched or outperformed manual review.
Among Teams & Enterprise adopters, auto mode users ship about 25% more PRs.
In a controlled experiment with 1,053 paid professional testers, human review caught just 13.6% of dangerous commands, while auto mode caught 89%.
Research conducted internally and through several third parties suggests that auto mode is safer than how a typical user engages with permission prompts today.
編集コメントを表示
編集コメント
Anthropic は安全性への懸念をデータで解消し、開発ツールのデフォルト動作を自動化する大胆な決断を下した。これは AI エージェントが人間に依存せず自律的に作業を進める時代の到来を示唆している。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
Claude Code のデフォルト設定を「自動モード(auto mode)」に変更します。8 月 14 日から、Pro、Max、Team プランの新しいセッションはすべて自動モードで実行されます。
もしあなたが以前に別のデフォルトを手動で設定していた場合、一度だけ「自動モードに切り替えるか」という確認プロンプトが表示される可能性があります。ただし、デフォルトを固定(ピン留め)している場合は、変更はありません。
自動モードではツール呼び出しごとに追加のトークンを若干使用しますが、本日付で Pro、Max、Team プランのユーザーに対するこの分類器オーバーヘッドの利用料は無料化されます。
現在、Claude Enterprise、Claude API、AWS 上の Claude Platform、Amazon Bedrock、Google Cloud の Agent Platform、Microsoft Foundry では、自動モードは引き続きオプトイン(任意参加)のままです。これは管理者が変更内容をレビューする猶予を与えるためです。
今後 1 ヶ月以内にクラウドパートナーと連携し、これらのプラットフォームすべてで自動モードをデフォルトに設定するとともに、分類器オーバーヘッドの利用料も無料化する予定です。その間、Enterprise の管理者は管理設定を通じて Claude Code の自動モードをデフォルトとして有効化できます。
オートモードは、ユーザーが邪魔されたくないという要望と、有害な行動を回避するシステムのバランスを取るために設計されています。プロンプトによる確認の代わりに、各ツール呼び出しは、不可逆的・破壊的な行為や外部環境への攻撃を対象とした分類器を経由してルーティングされます。分類器が何かをブロックした場合、Claude は通常、より安全な方法で独自に処理を進めるか、ユーザーに直接許可を求めるようになります。それでも進捗が得られない場合(連続 3 回またはセッション全体で 20 回のブロック)、Claude Code は手動承認モードに切り替わります。
過去数ヶ月間、オートモードが平均的なユーザーがプロンプトを確認するよりも安全である、あるいは同等の安全性を備えているかを検証してきました。内部レッドチーム、第三者によるレッドチーム、プロンプトインジェクション評価、1,053 名の有料テスターによる統制された研究、および実際の運用セッションの分析を行いました。テストしたすべての指標において、オートモードは手動レビューに匹敵するか、それ以上の性能を示しました。
また、オートモードにより Claude はより長時間自律的に作業できるようになります。これにより、Claude Opus 5 のように長時間実行を前提としたモデルが、大規模タスクに対して数時間にわたって稼働する実用性を高めています。ユーザーのオーバーヘッドを減らすことは、生産性の向上にもつながります。Teams & Enterprise の導入事例では、オートモード利用者が手動承認利用者よりも約 25% 多くの PR をリリースしています。Claude の作業を妨げないことで、タスクは中断なくより長く実行され、より多くの成果を生み出します。Adobe、Nuro、Gusto、Garner Health の各チームはすでに オートモードを生産環境のデフォルトとして運用 しています。
ここでは、今回の変更を促した安全性データと顧客からのフィードバック、そして必要に応じてデフォルト設定を変更する方法についてご紹介します。
手動レビューと自動モードの比較
データによると、手動レビューは習慣化されがちです。Claude Code では、ユーザーが許可プロンプトに同意する割合が 97% に達しています。多くのプロンプトが安全で日常的なコマンドに関するものですが、この高い承認率は、ユーザーが各コマンドを慎重に見直すのではなく、反射的に「承認」をクリックしている可能性を示唆しています。
これらのプロンプトは、開発者がプロジェクトの最中などに毎日数十回から数百回にわたる重要なセキュリティ判断を下すことを求めます。その結果、レビューの負担がユーザーに集中し、重要な事項を見逃してしまうリスクが高まります。一方、データはユーザーが他の種類の対話に対してはより厳しく検討し、反発することも示しています。例えば、Claude が提案した計画に対する承認では 39% が却下されています。しかし、個々の権限リクエストに対する却下率はわずか 3% です。
この傾向は設定ファイルにも見られます。2026 年 6 月時点での CLI ユーザーの 49.5% が手動で Bash の許可ルールを作成しています。そのうち 5% はあらゆるシェルコマンドを無条件に許可し、残りの 43% は Bash(python:*) や Bash(node:*) といった解釈器ルールを設定しており、実質的には前者と同様の効果を持っています。この割合は約 5 ヶ月ごとに 5 ポイントずつ増加しています。
許可ルールの設定以外にも、62% のユーザーが bypassPermissions を使用するか、Bash で「次回から聞かない」をクリックしています。また、対話セッションの 25% は権限バイパスモードで開始されています。
自動モードでは、許可ルールは分類器よりも先に実行されます。ただし、任意のコード実行を許可する広範なルール(例:python:*)は例外です。これらの任意のルールは、自動モード中は一時保留され、コマンドが分類器を完全にバイパスしてしまうのを防ぎます。設定ファイル自体は変更されず、他のモードに切り替えた瞬間にルールが再び適用されます。
自動モードによる安全性の向上
社内および複数の第三者機関で行った調査によると、自動モードは現在の一般的なユーザーが許可プロンプトに対応する方法よりも安全であることが示されています。開発者が実際に許可プロンプトをクリックして承認する行為と、自動モードを比較したテストでは、以下のすべての測定項目において、自動モードは人間の承認に匹敵するか、それ以上の性能を発揮しました。
- 社内レッドチーム演習
- 第三者によるペネトレーションテスト
- 実際のセッションの分析
安全性における自動モードと手動許可の比較

ある研究ベンダーを通じて、コーディングに関する調査のために 1,053 名の有償テスターを募集しました。参加者は調査用に特別に設定されたテスト環境で作業を行い、自身のコードベースや実際のプロジェクト上で作業したわけではありません。参加者には評価が行われていることを伝えていましたが、盲検試験の標準的な設計に従い、どの行動が測定されているのかは伝えられていませんでした。
セッションの途中、単一の権限プロンプトを明らかに危険なコマンドに差し替えました。ベンダーはテスターがそのプロンプトを承認したかどうかを記録しました(注:プロンプトを承認しても実際に危険なことが実行されることはなく、テスターが目にしたプロンプトのテキストのみを変更しています)。
テスターたちは危険なコマンドをただ 13.6% の場合(1,053 件中 143 件)にしか検出できませんでした。一方、自動モードは同じコマンドの 89%(1,053 件中 937 件)をブロックしました。直接比較すると、自動モードは人間が承認した 800 件のコマンドをブロックしましたが、人間は自動モードが許可した 6 件のコマンドのみをブロックしました。
セッションが長くなるにつれて人間の検出能力は低下しました。セッション初期には危険なコマンドの約 17% をブロックしていましたが、50 件以上のプロンプトを経過した後では約 5% にまで低下しました。一方、自動モードのブロック率はセッションの長さに関わらず一定でした。
自動モードは有害な行動をより多く防止する
私たちの調査によると、自動モードは手動権限モードよりも有害な行動を減らす効果があります。
私たちは、自動モードが実際の使用シーンでどのように機能するかを検証しました。2026 年 5 月から 6 月にかけて、安全パイプラインによってレビュー対象としてフラグ付けされたセッションを分析しました。分析に用いたデータは、トレーニングおよび分析でのデータ利用にユーザーが同意したアカウントからのみ抽出しています。
各セッションについて、0 から 10 の2段階の尺度を用いて再評価を行いました。最初の尺度は「危害の深刻度」です。10 は会社全体に影響する不可逆的な損害(例:会社の全ソースコードの漏洩)、7 は本番環境レベルの重大な問題(例:本番データベースからの行削除)、0 はローカルワークスペース内に限定された完全に元に戻せる操作(例:一時ファイルの上書き)を指します。
2 つ目の尺度は、ユーザーがその行動をどの程度明確に指示したかです。これにより、ユーザーが直接要求した有害な行為と、より曖昧な指示のもとでエージェントが行った有害な行為を区別できます。
レビュー対象となったセッションのうち、手動承認を経たものでは、意図しない重大な危害が発生する頻度が自動モードのセッションの2倍以上でした。本番環境レベル(7 以上)の深刻度において、ユーザーが明示的に要求していない有害な行動が含まれる割合は、手動承認セッションで6.3%、自動モードセッションで2.4%でした。この差は、テストしたすべての深刻度レベルで確認できました。
敵対的レッドチームングにより自動モードが強固に
私たちは英国の AI セーフティスタートアップである Apollo Research と協力し、実際のコーディングプロセスに合成攻撃を注入する2週間のパイロット実験を行いました。この実験は、広範な失敗、データ流出、および安全性に関連する脅威を対象とした3つのデータセットで実施されました。
今回の対応は、標準的な「発見・特定・検証」のループに基づいて行われました。Apollo 氏は、成功した攻撃事例と、自動モードを強化するための推奨事項を共有しました。私たちは主に、保護対象環境に関する文脈(リポジトリの可視性、Git の状態、および後述するデータ処理ルール)を分類器に追加することで、これらの攻撃に対する防御力を高めました。
防御力の強化後、Apollo 氏が共有しなかった独立したテストセットで再検証を行いました。その結果、自動モードは以前見逃していた攻撃の約半分を検出できるようになりましたが、一方で以前正しく検出できていた攻撃の約 2% を見逃すようになりました。外部に公開されていないテストセットに対してチューニングを行っていないため、今回の強化は Apollo 氏が共有した特定の攻撃への対応ではなく、新しい攻撃にも一般化して機能していることが示唆されます。共有されたセットと独立したセットを合わせた全体で見ると、分類器の見落とし率は 12% から 7% に低下しました。
これらの攻撃は、分類器の弱点を突くように設計された合成かつ敵対的なものであり、何らかのプロンプトを与えられた場合でも Claude が行うことよりも悪意に満ちています。この 7% という見落とし率は、こうした人工的に作成されたテストセットに対する数値であり、実際の運用トラフィックにおける見落とし率と誤解してはなりません。
Auto mode reduces prompt injection risk

自動モードを有効化すると、独立した評価においてどのモデルに対する攻撃も成功しませんでした。Codex v0.144.5 の自動レビュー許可モードで動作する GPT-5.6 Sol は、攻撃成功率が 5.83% を記録しました。GPT-5.6 Sol は最高レベルの推論能力でのパフォーマンスを検証するため「max」の推論努力設定で実行され、すべての Claude モデルは高努力設定でテストされました。
自動モードの分類器は、エージェントに対してユーザーの指示から逸脱させることを試みる プロンプトインジェクション攻撃 に対する追加防御層として機能します。自動モード実行時には、ツールの結果がプローブによってスキャンされ、悪意のある指示が含まれていないか確認されます。また、自動モードはアクションがユーザーの意図と整合しているかをチェックします。この深層防御アプローチの有効性を示すため、自動モードをガードされていないモデルと比較してテストを行いました。
私たちは第三者のトラジェクトリー・ラボ(Trajectory Labs)に評価を委託し、2026 年 7 月 17 日時点で公開されている Claude Code と Codex の最新バージョンに含まれるさまざまなモデルを検証しました。彼らは Anthropic が保有する 72 の間接プロンプトインジェクションシナリオをテスト対象としました。各シナリオは 10 回ずつ実行され、成功すれば非テスト環境では機密データの漏洩、金銭的詐欺、認証情報のフィッシングなどユーザーに不可逆的な被害をもたらす攻撃が実現します。
この攻撃手法は Claude Opus 4.7 を最適化して設計されたものですが、同モデルは今回の評価対象セットには含まれていません。そのため、評価に参加したすべてのモデルにとってこれらの攻撃は未知のものとして扱われました。自動モード(auto mode)に加え、Claude Code の*bypassPermissions*モードと Codex の*Full Access*モードについても検証を行いました。
Codex と Claude Code は、トラジェクトリー・ラボが作成した同一のブラウザ統合環境を用いて評価されました。この統合は navigate などの一般的な Chrome API を薄いラッパーで包んだ MCP ツール群を提供します。OpenAI や Anthropic が提供する Chrome 拡張機能など、ファーストパーティ製のブラウザ統合に組み込まれているセーフガードについては今回のテストでは対象外です。したがって、本結果は特定のデプロイメント環境における包括的なセキュリティ対策全体を評価したものではなく、基盤となるモデル自体の能力を測定したものと捉える必要があります。
今回の評価では、自動モードで動作している Claude 3.5 Sonnet、Opus、または Haiku のいずれに対しても、720 回の攻撃試行のうち成功したのはゼロでした。一方、GPT-4o(Codex の「自動レビュー」モード)に対しては 5.83% の攻撃が成功しました。これは、追加の安全対策を施さない状態で「バイパス権限」モードで動作する当社の最新モデルに対する平均攻撃成功率 0.09% を大きく上回る数値です。また、「フルアクセス」モードで動作する GPT-4o に対しては、19.03% の攻撃が成功しました。
ツールが結果をテキストとして返すタスクと、スクリーンショットを通じてブラウザと対話する必要があるタスクでは、攻撃の成功率に違いが見られました。詳細は以下の通りです。


自動モードは、ツールの呼び出し時およびブラウザの GUI を使用する際の両方で、プロンプトインジェクションからユーザーを守ります。なお、第三者の評価では、OpenAI のモデルがブラウザ関連タスクにおいてより高い攻撃成功率を示しました。
Anthropic 内部で自動モードが防止した 3 つの事例
Anthropic 社内での Claude Code の利用においても、自動モードはデフォルト設定となっています。以下に、分類器によって内部で阻止された具体的な行動を 3 つ紹介します。
オフライン環境でのデータ漏洩:内部ドライブへのアップロードに失敗した際、Claude のフォールバック機能は同じレポートを公開コード共有サイトに投稿しようとした。しかし Auto モードがこれを拒否し、ユーザーに対して次の手順を確認するよう促しました。
破壊的な一括操作:長時間実行されたセッションにおいて、Claude は約 2,000 ポッドに対する一括プロセス終了を試み、進行中のトレーニングジョブを数百基の GPU で実行していた環境を崩壊させるような削除キューを作成しようとしていました。Auto モードが実行前にこれらの破壊的コマンドを検知し、阻止しました。
権限昇格の過剰適用:読み取り専用の請求書アクセス権限を付与するよう依頼された際、Claude はアカウントルートレベルで完全な管理権限を持つクラウドロールを指定しようとしていました。Auto モードが、要求された権限と実際に付与されるロールとの不一致を検出しました。
いずれのケースでも、Claude は自らより安全な経路を見つけ出したか、または実行前にユーザーに確認を取ることで対応しました。
Auto モードのさらなる安全性向上
私たちは、生産環境へのコードリリースをより安全かつ容易にするための新機能に継続的に投資しています。最近の事例としては:
・**ハード拒否**: データの持ち出し、つまりコードやシークレットを外部へ送信する行為は、分類器が絶対に許可しないカテゴリに位置づけられています。そのようなアクションを実行するには、オートモードから切り替えるか、自分でコマンドを実行する必要があります。ハード拒否ルールは設定を通じてカスタマイズ可能で、組織内のユーザーからのリクエストがあったとしても決して許可したくない追加ルールを設定できます。
・データアクセスと共有に関するルール: 分類器には現在、シークレットや機密性の高い情報(潜在的に機密情報が含まれるもの)を明確に区別するルールが組み込まれており、それぞれどこでアクセス・共有できるかが定義されています。これらのルールを実効性のあるものとするため、アクション実行前に git push やプルリクエストの宛先が公開、非公開、あるいは信頼済みかどうかを確認します。同じプッシュ操作でも、どこへ転送されるかで「日常業務」か「データ持ち出し」かが分かれます。チームのプライベートリポジトリに属するコードがパブリックなリポジトリに流れ出るような事態を、分類器は検知して警告するように設計されています。
・破壊的な git 操作前のステータス確認: git reset --hard のように未コミットの変更を破棄する可能性があるコマンドを実行する際、分類器はリポジトリの現在の git ステータスを参照し、オートモードが何のリセット対象となっているかを把握できるようにしています。
プロンプトインジェクションのスクリーニング:Claude が Web ページ、ファイル内容、ツールの出力など外部ソースからコンテンツを取得する際、API 側でその内容をスキャンし、Claude の動作を乗っ取ろうとする試行がないかチェックします。インジェクションの兆候が検出されると、結果をユーザーに共有する前に警告文をコンテキストに追加します。
本番環境でのオートモード
すでに多くのチームが、本番環境のデフォルトとしてオートモードを採用しています。
- Adobe のマーチャンダイジングプラットフォームチームは、90 カ国以上、30 以上の言語に対応する Adobe.com 上の価格情報やプロモーションページの正確性と最新性を維持する責任を負っています。彼らはページ作成と検証のためのエージェントループを構築し、これをオートモードで実行することで、エンジニアがレビュー対象として完成したプルリクエストを受け取れるようにしています。
- Nuro は研究部門からエンジニアリング部門まで組織全体でオートモードを採用しており、夜間に評価指標の向上を目指すハイブリッド検索を行う研究エージェントを稼働させ、朝にはレビュー可能な状態のプルリクエストが提出される仕組みを作っています。
- Gusto は、権限チェックを迂回しようとするエンジニアが増えるという「権限疲れ」の問題を解決するため、オートモードを導入しました。5 月中旬以降のセッションの約 10% で分類器による拒否が発生していますが、これは正当なタスクを阻害することなく、実際に機能している証拠です。
- Garner Health は、管理設定を通じて全社 550 名の従業員に対してオートモードをデフォルトとして適用し、手動でコマンドの許可リストを構築する必要のない、会社全体に統一されたソフトウェア開発ライフサイクル(SDLC)を実現しました。
これらの顧客が、本番環境で自動モードをどのように活用しているかを見てみましょう。
使い始め
Pro、Max、Team ユーザーの場合、デフォルトの許可モードを設定していないと、製品内で通知が表示され、新しいセッションは自動的に自動モードで開始されます。すでに別のデフォルトを設定している場合は、一度だけ「デフォルトを自動モードに切り替えるか」というプロンプトが表示される可能性があります。ただし、チーム管理者が管理設定でデフォルトを指定している場合、あなたには変更はありません。
Enterprise ユーザーや Claude API を通じて Claude Code にアクセスするユーザーの場合、現在も自動モードはオプトイン(任意参加)のままです。来月中に自動モードをデフォルトに切り替える予定であり、その前に Enterprise 管理者へ通知を行います。
モードの切り替えには、CLI で Shift+Tab を押すか、デスクトップアプリのモードドロップダウンを使用してください。管理者は、管理設定 の defaultMode を使用して組織全体のデフォルトを固定できます。また、disableAutoMode で自動モード自体を無効化することも可能です。
最後に、自動モードがほとんどのユーザーにとってリスクを低減すると考えていますが、これは分類システムに依存しているため、リスクを完全に排除するものではありません。本番環境のインフラに対する重大な変更を行う際は、Claude の実行内容を必ず自分で確認することをお勧めします。完全な設定手順については、自動モードの設定ドキュメントをご覧ください。
この記事はコンナー・フィリッピが執筆し、ニコラス・カリーニ、アイザック・ファン、ジョン・ヒューズ、アレックス・イスクエン、ショーン・ムーア、ハビエル・ランド、モリー・ヴォーバークの協力を得て作成されました。また、ヤシン・アズミ、チャンドラー・ベアー、ケファン・チェン、ボリス・チェルニ、イアン・グルネルト、リディア・ホーリー、アレックス・クレイマン、ローレン・ポランスキー、デオン・ポンチーニ、ロバート・ショーンバーガー、マリー・ヴァチョフスキー、Qing Wang、キャット・ウー、ダニエル・シュウ、アリス・ジャオにも感謝いたします。
1 Claude Code v2.1.205 と Codex v0.144.5 を評価しました。OpenAI は先週、結果に影響を与える可能性のある Auto-review の新バージョンをリリースしています。
該当する項目は見つかりませんでした。
原文を表示
We're making auto mode the default in Claude Code. Starting on August 14, new sessions on Pro, Max, and Team plans will run in auto mode. If you've already set a different default yourself, you may get a one-time prompt asking whether you want to switch to auto mode. If you have a pinned default, nothing changes for you. The auto mode classifier uses a small number of extra tokens per tool call, and we're no longer charging Claude Code users on Pro, Max, and Team plans for that classifier overhead, effective today.
Auto mode remains opt-in for now on Claude Enterprise, the Claude API, Claude Platform on AWS, Amazon Bedrock, Google Cloud's Agent Platform, and Microsoft Foundry, giving admins time to review the change. In the coming month, working with our cloud partners, we plan to make it the default across all of these and no longer charge for classifier overhead. In the meantime, Enterprise admins can make Claude Code's auto mode the default through managed settings.
Auto mode is designed to balance users’ desire not to be interrupted with a system that helps avoid harmful actions: instead of prompts, it routes each tool call through a classifier targeted at blocking actions that are irreversible, destructive, or aimed outside your environment. When the classifier blocks something, Claude usually finds a safer way to proceed on its own or asks you directly for the go-ahead; if it can't make progress—three blocks in a row, or twenty across a session—Claude Code falls back to manual approvals.
We spent the last several months testing whether auto mode is as safe or safer than an average user clicking through prompts. We ran internal red-teaming, third-party red-teaming and prompt-injection evaluations, a controlled study with 1,053 paid testers, and analysis of real production sessions. On every measure we tested, auto mode matched or outperformed manual review.
Auto mode also lets Claude work autonomously for longer stretches. This makes models built for long-running work, like Claude Opus 5, more practical to leave running for hours on large tasks. Reducing overhead for users also increases output. Among Teams & Enterprise adopters, auto mode users ship about 25% more PRs. Unblocking Claude allows tasks to run longer uninterrupted and get more work done. Teams at Adobe, Nuro, Gusto, and Garner Health already run auto mode as their production default.
Below, we share the safety data and customer results motivating the change, and how to set a different default if you prefer.
Comparing manual review to auto mode
Data suggests that manual review can become habitual: users approve 97% of permission prompts in Claude Code. While most prompts are likely for safe, routine commands, an approval rate that high suggests many users are clicking through reflexively rather than reviewing each command. These prompts ask developers to make dozens or hundreds of important security decisions every day, often in the middle of projects, which places the review burden on users and increases the chance that something important slips through the cracks. Data also suggests that users more frequently scrutinize and push back on other types of dialogues: for example, when Claude presents a plan for approval, users reject 39% of them. But for individual permissions requests, the rejection rate is only 3%.
The same pattern shows up in settings files. As of June 2026, 49.5% of active CLI users have manually created a Bash allow-rule—5% allow any shell command outright, and another 43% have interpreter rules like Bash(python:*) or Bash(node:*) that are essentially equivalent in practice—and that share is growing roughly 5 percentage points every 5 weeks. Beyond allow-rules, 62% of users have used bypassPermissions or clicked “don't ask again” on Bash, and 25% of interactive sessions start in bypass permissions mode.
Permission rules still fire before the classifier in auto mode, except for allow rules broad enough to grant arbitrary code execution (e.g. python:*). These arbitrary rules are set aside while in auto mode, since they would let commands skip the classifier entirely. Settings files aren't modified, and the rules apply again the moment you switch to another mode.
Improving safety with auto mode
Research conducted internally and through several third parties suggests that auto mode is safer than how a typical user engages with permission prompts today. We tested auto mode against what developers actually approve when they're clicking through permission prompts. Across each of these measures—internal red-teaming, third-party penetration testing, and analysis of real-world sessions—auto mode matched or outperformed human approval.
Auto mode outperforms manual permissions on safety

We hired 1,053 paid testers through a research vendor for a coding study. These participants worked in a test environment set up specifically for the study, not in their own codebases or on real projects. Participants knew they were being evaluated, but—following standard blind-study design—weren't told which behavior was being measured. Partway through each session, a single permission prompt was swapped for a clearly dangerous command, and the vendor recorded whether the tester approved it (Note: approving the prompt never resulted in anything dangerous being run; only the text of the prompt testers saw was changed).
The testers caught the dangerous command just 13.6% of the time (143 of 1,053), while auto mode blocked 89% of the same commands (937 of 1,053). Head to head, auto mode blocked 800 commands that a human approved, while humans blocked only 6 that auto mode allowed. As sessions got longer, humans did worse: they blocked about 17% of dangerous commands early in a session, dropping to about 5% after 50 or more prior prompts, while auto mode's block rate stayed flat regardless of session length.
Auto mode prevents more harmful actions
Our research also suggests that auto mode leads to fewer harmful actions than manual permissions mode.
We examined how auto mode performs in real usage. From May to June 2026, we examined sessions our safety pipeline had flagged for review, drawn only from accounts that have opted in to data use for training and analysis. We re-graded each one with a model on two 0–10 scales. The first was harm severity with 10 being company-wide, irreversible harm, such as leaking a company's entire source code, 7 representing production-level severity such as deleting rows from a production database, and 0 a fully reversible action confined to the local workspace, like overwriting a scratch file. The second was how explicitly the user had asked for the action, so we could separate harmful actions the user directly requested from harmful actions the agent took with less explicit direction.
Among the flagged sessions, those that went through manual approval contained serious unintended harm more than twice as often as auto mode sessions. At production-level severity (7+), 6.3% of manually approved sessions contained a harmful action the user hadn't explicitly asked for, compared to 2.4% of auto mode sessions, and the gap held at every severity level we tested.
Adversarial red-teaming made auto mode stronger
We worked with Apollo Research, a UK-based AI safety startup, on a two-week pilot injecting synthetic attacks into real coding trajectories, across three datasets covering broad failures, data exfiltration, and safety-related threats.
The engagement followed a standard find-fix-verify loop. Apollo shared a set of successful attacks along with recommendations to strengthen auto mode. We hardened the classifier against them primarily by giving it more context about the environment it's protecting (repository visibility, git state, and the data-handling rules described below).
After hardening, Apollo re-tested on a separate held-out attack set that we never had access to. Auto mode caught about half of the attacks it previously missed, at a cost of missing about 2% of attacks it previously caught. Since we couldn't tune against the held-out set, this suggests the hardening generalizes to new attacks rather than patching the specific ones Apollo shared. Across both the shared and held-out sets, the classifier's miss rate fell from 12% to 7%.
These attacks are synthetic and adversarial by design, built to find where the classifier fails, and more malicious than anything Claude would do unprompted. The 7% miss rate is measured against this set and should not be taken as the miss rate on real traffic.
Auto mode reduces prompt injection risk

The auto mode classifier adds an additional layer of defense against prompt injection attacks that try to force the agent to deviate from the user’s instructions. When running with auto mode, tool results are scanned by probes for potentially malicious instructions, and auto mode checks that actions are aligned with user intent. We tested auto mode compared to an unguarded model to illustrate the power of this defense-in-depth approach.
We commissioned an evaluation from a third party, Trajectory Labs, who tested different models within the latest publicly available versions of Claude Code and Codex as of July 17th 2026.1 They tested 72 indirect prompt injection scenarios held out from Anthropic. Each scenario was tested 10 times. Successful attacks would, in a non-testing environment, result in irreversible actions that could harm the user such as sensitive-data exfiltration, financial fraud, or credential phishing. The attacks were optimized against Claude Opus 4.7, which is not in the reported set, so every model in the evaluation faced them as unseen attacks. In addition to auto mode, the evaluations looked at Claude Code’s *bypassPermissions* mode and Codex’s *Full Access* mode.
Both Codex and Claude Code were evaluated using an identical browser integration produced by Trajectory Labs, PBC. This integration provides a set of MCP tools which are a thin wrapper around common Chrome APIs such as navigate. Safeguards built into first-party browser integrations such as the Chrome extensions provided by OpenAI and Anthropic were not tested. As such, these results should be viewed as a measurement of the underlying model, rather than the complete set of safeguards which might exist in a given deployment.
In this evaluation, none of the 720 attack attempts succeeded against Claude Fable 5, Opus 5, or Sonnet 5 running auto mode. On the other hand, 5.83% of the attacks succeeded against GPT-5.6 Sol running Codex's *Auto-review* mode. Notably, this is greater than the 0.09% average attack success rate against our latest models running in *bypassPermissions* mode without additional safeguards. The tests showed a 19.03% attack success rate against GPT-5.6 Sol when running in *Full Access* mode. Attack success rates differ between tasks where tools return results as text and tasks that require interacting with a browser through screenshots, as shown below.


Three incidents auto mode prevented inside Anthropic
Auto mode is also the default for all Claude Code internal usage at Anthropic. Here are three actions the classifier prevented internally:
- An off-network data leak: When an upload to an internal drive failed, Claude's fallback was to publish the same report to a public code-sharing site. Auto mode denied the fallback and prompted the user for next steps.
- A destructive mass operation: In a long-running session, Claude attempted a mass process kill across roughly two thousand pods and queued deletions that would have torn down hundreds of GPUs of in-flight training jobs. Auto mode flagged the destructive commands before execution.
- Over-broad privilege escalation: Asked to provision read-only billing access, Claude reached for a cloud role that grants full administrative control at the account root. Auto mode caught the mismatch between what was requested and what roles would have been granted.
In each case, Claude either found a safer path on its own or checked in with the user before proceeding.
Making auto mode even safer
We’re continuously investing in new auto mode features that make it safer and easier to ship production code. Recent examples include:
- Hard denies: Data exfiltration, like sending your code or secrets somewhere external, sits in a category the classifier is designed to never approve. To run an action like that, you have to switch out of auto mode or run the command yourself. Hard deny rules are customizable via settings so you can add more rules that you never want allowed even when requested by users in your organization.
- Rules for data access and sharing: The classifier now carries explicit rules distinguishing secrets and potentially sensitive/confidential information—and where each can be accessed and shared. To make those rules enforceable, it also checks whether the destination of a git push or pull request is public, private, or trusted before the action runs. The same push can be routine or an exfiltration depending on where it lands: code that belongs in your team's private repository shouldn't end up in a public one, and the classifier is now designed to flag when this might happen.
- Checking git status before destructive git actions: Before a command that could discard uncommitted work, like git reset --hard, the classifier sees the repository's current git status, letting auto mode know what is being reset.
- Prompt injection screening: When Claude pulls content from external sources, like web pages, file contents, or tool outputs, an API-side probe checks that content for attempts to hijack Claude's behavior. When something looks like an injection attempt, a warning is added to Claude's context before the result is shared with the user.
Auto mode in production
Teams are already running auto mode as their production default:
- Adobe's merchandising platform team is responsible for keeping pricing and promotional pages accurate and current across 90+ countries and 30+ languages on Adobe.com. They built an agentic loop to build and verify those pages, running it in auto mode so engineers receive finished PRs for review.
- Nuro runs auto mode across its research and engineering orgs, using it to power overnight research agents that hill-climb evaluation metrics and return finished PRs for review by morning.
- Gusto adopted auto mode to end the permission fatigue that was pushing engineers toward bypassing permissions checks entirely. About 10% of sessions since mid-May include a classifier denial—evidence it's doing real work without slowing legitimate tasks.
- Garner Health pushed auto mode as the default to all 550 employees via managed settings, standardizing a company-wide software development lifecycle (SDLC) that no longer depends on hand-curated command allowlists.
eBook
Learn how these customers are running auto mode in production.
Getting started
For Pro, Max, and Team users: if you haven’t set a default permission mode, you’ll receive an in-product notice and new sessions will start in auto mode automatically. If you've set a different default, you may see a one-time prompt asking if you’d like to switch your default to auto mode. If your Team admin has set a default in managed settings, nothing changes for you.
For Enterprise users and users who access Claude Code via the Claude API, auto mode remains opt-in for now. We plan to make auto mode the default in the coming month, and we’ll notify Enterprise admins before we do.
To switch modes, press Shift+Tab in the CLI or use the mode dropdown on the desktop app. Admins can pin an org-wide default with defaultMode in managed settings, or turn auto mode off entirely with disableAutoMode.
Finally, while we believe auto mode reduces risk for most users, it relies on classification systems and therefore does not eliminate risk. For high-stakes changes to production infrastructure, we still recommend reviewing Claude's actions yourself. See the auto mode docs for full configuration instructions.
*This article was written by Conner Phillippi, with contributions by Nicholas Carlini, Isaac Fung, John Hughes, Alex Isken, Shawn Moore, Javier Rando, and Molly Vorwerck. The authors would also like to thank Yacine Azmi, Chandler Bair, Kefan Chen, Boris Cherny, Ian Grunert, Lydia Hallie, Alex Kleiman, Lauren Polansky, Deon Poncini, Robert Schonberger, Marie Vachovsky**, **Qing Wang, Cat Wu, Daniel Xu, and Alice Zhao.*
1 We evaluated Claude Code v2.1.205 and Codex v0.144.5. OpenAI released a new version of Auto-review last week that could change the results.
No items found.
関連記事
News to Guide
ニュースの次に確認する
発表内容を、現在の料金や仕様と照らし合わせられる関連ガイドです。
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み