ガイド

著者 Matt Connor 2026-08-09 ・更新日 2026-08-13

Claude Codeのauto modeがデフォルトに変更

Q: サーバー上の全員が auto mode や bypass mode を使用できないようにするにはどうすればよいですか？

permissions.disableAutoMode と permissions.disableBypassPermissionsMode を、/etc/claude-code/managed-settings.json 内で文字列 "disable" に設定してください。管理対象の設定は他のすべてのスコープより優先されるため、ユーザー設定ファイルやコマンドラインフラグで上書きできません。disableAutoMode により Shift+Tab のサイクルから auto が削除され、起動時に --permission-mode auto が拒否されます。disableBypassPermissionsMode はどのスコープからでも使用できるため、単一のユーザーが自身の ~/.claude/settings.json に設定することもできます。

Q: defaultMode: "auto" の設定が無視されるのはなぜですか？

設定したファイルが正しくないためです。Claude Code v2.1.142 以降では、defaultMode: "auto" が .claude/settings.json または .claude/settings.local.json から指定されている場合、リポジトリが設定ファイルを配布して自身に auto mode を許可できないように無視されます。セッションは default モードで開始され、エラーは出力されません。設定を ~/.claude/settings.json に移動し、/permissions を実行して、現在有効な各ルールの出所ファイルを確認してください。それでも auto mode を利用できない場合は、モデルの要件を確認してください。Sonnet 4.5 などの古いモデルは、どのプロバイダーでもサポートされていません。

2026年8月14日から、Pro、Max、Teamの新規セッションはauto modeで開始します。6つの権限モードの違いと、監視できないVPSで選ぶべき設定を解説します。

2026 年 8 月 14 日に auto mode で変わること

Claude Code の auto mode は、確認を求めて停止せずにツール呼び出しを実行します。また、各アクションを別の classifier model に送り、事前にレビューします。2026 年 8 月 14 日から、Pro、Max、Team プランでは、新しいセッションがこのモードで開始されます。モードはいつでも切り替えられます。すでに自分で設定したデフォルト値が上書きされることはありません。

ドキュメントでは、変更内容を次のように説明しています。

2026 年 8 月 14 日から、Pro、Max、Team プランでは、新しいセッションのデフォルトの permission mode が auto mode になります。モードはいつでも切り替えられます。自分で設定したデフォルト値は、1 回限りの切り替えプロンプトを受け入れない限り維持されます。組織が管理するデフォルト値は変更されません。

ここでは、日付より重要な点が 2 つあります。自分の設定ファイルで設定した defaultMode は、変更後も維持されます。組織が managed settings で適用したデフォルト値も維持されます。発表記事では、ロールアウト初期には Enterprise プランと API を使用するアカウントでは auto mode が引き続き任意であることも説明されています。

VPS（virtual private server）で Claude Code を実行している場合、この変更が適用される前に確認しておく価値があります。permission prompt は、キーボードの前にいるユーザーを必要とするチェックポイントです。リモートサーバーではその場にいないことが多いため、セッション開始時のモードが、その後数時間にわたって維持されるモードになります。

Claude Code の権限モード（監視が多い順）

モードは 6 つあります。各行の先頭にある名前が、settings に記述する値、または --permission-mode に渡す値です。

default: 新しいツールを使用するたびに Claude が確認します。作業ディレクトリ内の読み取りは、確認なしで実行されます。CLI（command line interface）ではこのモードを Manual と表示し、Claude Code v2.1.200 以降では manual を別名として使用できます。
plan: Claude はファイルを読み取り、調査のためにコマンドを実行しますが、ソースは編集しません。計画を承認するまで、編集はブロックされます。
acceptEdits: ファイル編集と、mkdir、touch、rm、rmdir、mv、cp、sed のファイルシステムコマンドを確認なしで実行します。対象は、作業ディレクトリ内または additionalDirectories 内のパスに限られます。それ以外の shell コマンドでは、引き続き確認を求められます。
auto: すべての操作を実行します。ただし、classifier が各操作を事前に確認します。明示的な ask ルールがある場合は、引き続き確認を求められます。
dontAsk: 確認を求めるはずの操作を Claude Code が自動的に拒否します。実行されるのは、allow ルール、組み込みの読み取り専用 Bash コマンド、および PreToolUse hook が承認した呼び出しだけです。セッションが入力を待つことはありません。
bypassPermissions: 確認と安全性チェックを省略します。.git や .claude などの保護されたパスへの書き込みも対象です。

セッション中に Shift+Tab を押すと、default、acceptEdits、plan の順に切り替わります。ステータスバーには、⏵⏵ auto mode on や灰色の ⏸ manual mode on など、現在のモードが表示されます。その他のモードは、デフォルトではこの切り替え対象に含まれません。アカウントが要件を満たすと、auto が切り替え対象に加わります。セッションを --permission-mode bypassPermissions または --dangerously-skip-permissions で開始した場合のみ、bypassPermissions が切り替え対象に加わります。dontAsk はそこには表示されないため、claude --permission-mode dontAsk で設定します。

Auto mode には新しいモデルも必要です。Auto mode がまったく表示されない場合、その要件が原因であることが一般的です。2026 年 8 月時点のドキュメントには、Anthropic API で Claude Opus 4.6 以降、Sonnet 4.6 以降、および Fable 5 が必要と記載されています。また、Sonnet 4.5 などの古いモデルは、どのプロバイダーでもサポートされないと説明されています。Claude Code が Auto mode を利用できないと表示する場合、これらの要件のいずれかを満たしていません。一時的な障害ではないため、待っても解決しません。

bypassPermissions を含むすべてのモードで、2 つの制御が有効です。deny ルールと明示的な ask ルールです。セッションの開始時にどのモードを選んでも、これらの設定は維持されます。

自動モードの分類器がブロックする操作

分類器は、保留中の操作を読み取り、それが依頼内容に合っているかを判断する第2のモデルです。ドキュメントでは、その役割を次の1文で説明しています。

別の分類モデルが実行前に操作を確認し、依頼内容を超えて権限を拡大する操作、認識されていないインフラストラクチャを対象とする操作、Claude が読み取った悪意のあるコンテンツに誘導されたと見られる操作をブロックします。

サーバー運用でよく遭遇する次のカテゴリは、デフォルトでブロックされます。

コードのダウンロードと実行（curl | bash など）
本番環境へのデプロイとマイグレーション
Force push
共有インフラストラクチャの変更
ローカルサービスをパブリックインターネットから到達可能にするトンネルまたはリバースシェルの開設
有効な credential または token をトランスクリプトやファイルに出力する操作

次の操作は、デフォルトで許可されます。

作業ディレクトリ内のローカルファイル操作
lock ファイルまたは manifest で宣言された依存関係のインストール
読み取り専用の HTTP リクエスト
作業中のリポジトリにある任意のブランチへの push

上記のような要約だけを根拠に運用しないでください。claude auto-mode defaults を実行して完全なルール一覧を JSON で出力し、インストール済みのバージョンに付属するルールセットを確認してください。

この機能を過信する前に、2つの制限を理解しておく必要があります。まず、分類器はメッセージ、tool call、CLAUDE.md の内容を確認しますが、tool の結果は除外されます。そのため、Claude が読み取ったファイルや Web ページ内のテキストから、分類器へ直接指示することはできません。次に、分類器が1回のセッションで操作を連続して3回、または合計で20回ブロックすると、自動モードが一時停止し、Claude Code はプロンプトによる確認に戻ります。これらのしきい値は設定できません。-p フラグを指定した非対話モードでは、確認を求める相手がいないため、ブロックが繰り返されるとセッション自体が中止されます。

リモートホストでは、この2つ目の挙動が問題になります。無人実行が上限に達すると処理が停止し、端末を確認していない担当者の入力を待ち続けます。エージェントに実行させる内容を絞ることも解決策の一つです。最小限の変更で目的を達成するようエージェントを誘導するスキルを使うと、分類器が停止させるような過剰な操作へセッションが逸れるのを防げます。

設定ファイル内の settings.json の場所

上記はすべて、設定ファイル内の1つのオブジェクトです。

{
  "permissions": {
    "defaultMode": "auto",
    "allow": [
      "Bash(npm run test *)",
      "Bash(git status)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(docker compose up *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Bash(curl *)"
    ]
  }
}

ルールは deny、ask、allow の順に評価されます。その順序で最初に一致したルールによって結果が決まり、後から指定した狭い範囲のルールが、先に指定した広い範囲のルールより優先されることはありません。Bash(aws *) に対する deny ルールがあると、同じコマンドを許可していても aws s3 ls はブロックされます。そのため、deny ルールに例外を設定することはできません。

ask は、auto モードで特に役立つルール種別です。auto モードでは通常の確認プロンプトが省略されますが、ask ルールを指定すると、人による確認が必要な特定のコマンドだけプロンプトを再表示できます。デプロイコマンドはここに指定します。コードを環境の外部へ出す前に確認を挟みたい場合は、Bash(git push *) もここに指定します。認証情報ファイルを deny に保持することも重要です。これは、そもそも認証情報をエージェントからアクセスできない場所に保管することと組み合わせて使用します。

設定ファイルは、優先度の低いものから次の順です。

~/.claude/settings.json: ユーザー設定です。すべてのプロジェクトに適用されます。
.claude/settings.json: プロジェクト設定です。リポジトリにコミットします。
.claude/settings.local.json: 1つのリポジトリ専用の個人設定です。git-ignored にします。
管理設定: 管理者がデプロイする設定です。Linux ではこのファイルが /etc/claude-code/managed-settings.json です。コマンドラインフラグを含め、管理された permission ルールを上書きするものはありません。

ここには、文書化された原因がある注意点があります。リポジトリが設定ファイルを配布して自ら auto モードを有効にできないようにするため、Claude Code v2.1.142 以降では .claude/settings.json または .claude/settings.local.json 由来の defaultMode: "auto" は無視されます。そこに設定すると、エラーをどこにも表示せずにセッションが default モードで開始されます。この行を ~/.claude/settings.json に移動してください。/permissions を実行すると、現在有効なすべてのルールと、そのルールの読み込み元ファイルを一覧表示できます。

モードを無効にする2つのスイッチ

管理者が使用できるキルスイッチは2つあり、どちらも boolean ではなく文字列 "disable" を指定します。

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

設定する場所について、ドキュメントは明確に説明しています。

bypassPermissions モードまたは auto モードが使用されないようにするには、任意の設定ファイルで permissions.disableBypassPermissionsMode または permissions.disableAutoMode に "disable" を設定します。これらは、上書きできない管理対象設定で特に有用です。

disableAutoMode は Shift+Tab のサイクルから auto を除外し、起動時に --permission-mode auto を拒否します。disableBypassPermissionsMode はバイパスモードに対して同じ役割を果たし、どのスコープからでも機能します。そのため、稼働中のサーバーで午前2時に使いたくないモードへ誤って切り替えないよう、自分の ~/.claude/settings.json に設定できます。他のユーザーも使うサーバーでは、代わりに両方を /etc/claude-code/managed-settings.json に設定してください。ユーザー設定ファイルはユーザーに属しますが、管理対象設定ファイルはユーザーに属さないためです。

VPS で auto mode を使うには分離境界が必要な理由

分類器は、一度に 1 つの操作を確認します。承認した操作がその後に何を実行するかまでは制限しません。ドキュメントでも、境界は明確に示されています。

分類器は操作ごとの制御であり、分離境界ではありません。そのため、無人実行では多層防御として分離境界を追加する必要があります。--dangerously-skip-permissions の場合のように必須というわけではありません。

したがって、リモートマシンでは auto mode と、失っても構わない環境を組み合わせます。bypassPermissions と希望だけに頼る構成ではありません。Bypass mode は、隔離された環境でのみ使用するものとして記載されています。対象は、コンテナ、仮想マシン、またはインターネットに接続されていない dev container です。これらの環境では、Claude Code がホストシステムに被害を与えません。データベースとリバースプロキシを実行している VPS は、どれにも該当しません。

サーバーでは、主に 3 つの対策が重要です。Claude Code は通常のユーザーとして実行し、root では決して実行しません。そのユーザーには作業ディレクトリだけを与え、読み取られると困るものにはアクセスさせません。マシンは修復するのではなく再構築します。これが、ジョブごとに破棄する一時 VM を使う理由です。ユーザー作成からファイアウォールルールまで、これらの対策の詳細は VPS で Claude Code を実行するための安全対策全体で説明しているため、ここでは繰り返しません。

Claude Code は root の使用を自ら制限します。Linux と macOS では、sudo で実行した場合、または root として実行した場合、bypass mode での起動を拒否します。

--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons

認識された sandbox 内では、このチェックは省略されます。そのため、自律的なコンテナ作業についてドキュメントが示している方法は、Claude Code を非 root ユーザーとして実行する dev container です。スマートフォンやラップトップから SSH 経由でエージェントを操作する場合も、同じ考え方が当てはまります。tmux で Claude Code のセッションを長時間維持する場合、セッションの実行中にプロンプトを監視する人はいないためです。

Bash sandbox を Ubuntu VPS に設定する

組み込みの sandbox は、Claude が実行するすべての Bash コマンドによるファイルシステムとネットワークへのアクセスを制限します。オペレーティングシステムは、子プロセスにもこの制限を適用します。Linux では、2 つのパッケージが必要です。

sudo apt-get install bubblewrap socat

Claude Code を起動し、/sandbox を実行します。Mode タブ、Overrides タブ、Dependencies タブを含むパネルが開きます。Dependencies タブには、不足している項目が表示されます。依存関係の確認は起動時に実行されます。そのため、パッケージをインストールした後に Claude Code を再起動してください。再起動しないと、パネルには依存関係が不足していると表示されたままになります。

Ubuntu 24.04 以降では、デフォルトの AppArmor ポリシーにより、bubblewrap が必要とする user namespace を作成できません。そのため、sandbox の起動に失敗します。システムに該当するか確認します。

sysctl kernel.apparmor_restrict_unprivileged_userns

0、または key が存在しないというエラーが表示された場合は、対応は不要です。1 が表示された場合は、bwrap 用のプロファイルが必要です。

sudo tee /etc/apparmor.d/bwrap > /dev/null <<'EOF'
abi <abi/4.0>,
include <tunables/global>

profile bwrap /usr/bin/bwrap flags=(unconfined) {
  userns,
  include if exists <local/bwrap>
}
EOF
sudo systemctl reload apparmor

このプロファイルが適用されるのは bwrap 自体です。sandbox 内で実行されるコマンドには適用されません。続いて、設定で境界を狭めます。

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "denyRead": ["~/"],
      "allowRead": ["."]
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

このブロックはプロジェクトの .claude/settings.json に記述してください。. がプロジェクトルートとして解決されるのは、プロジェクト設定からの場合だけです。同じ行を ~/.claude/settings.json に記述すると、. は ~/.claude として解決されます。その結果、denyRead ルールによってプロジェクトファイルへのアクセスがブロックされ、すべてのコマンドが編集対象のコードを読み取れなくなります。

この仕組みの対象外も把握しておいてください。sandbox が制限するのは Bash とその子プロセスです。組み込みのファイルツールは Claude Code プロセス内で実行されます。一方、MCP (model context protocol) サーバーと hook は、ホスト上で制限なしに実行される別プロセスです。これらすべてを 1 つの境界内に置くには、Claude Code プロセス全体をコンテナ、仮想マシン、または @anthropic-ai/sandbox-runtime パッケージ内で実行します。執筆時点で、これは beta の研究プレビューです。

各構成にはどのモードが適していますか？

自分の laptop 上の単独 repo

auto を使用し、実行結果を確認したい操作には ask ルールを設定します。操作するのは自分自身であり、classifier のフォールバックも実際に自分へ到達します。また、被害は自分が管理する 1 台のマシンに限定されます。14 August のデフォルトは、このケースを想定して定義されています。

共有 VPS

ユーザーごとに auto を使用し、それぞれのユーザー専用の ~/.claude/settings.json に設定します。Claude Code を実行するアカウントが root ではなく、他のユーザーの作業を読み取れないサーバーで運用してください。共有パスを保護する deny ルールとともに、disableBypassPermissionsMode を "disable" として /etc/claude-code/managed-settings.json に配置します。共有サーバーは bypassPermissions が不適切なことが最も明確に分かるケースです。このモードが前提とする分離境界が存在しないためです。他のテナントが、その境界の内側に存在するためです。

CI と自動実行セッション

dontAsk を使用し、ジョブに必要なコマンドを allow リストとして明示します。プロンプトを確認する人がいない場合、auto-deny が適切な失敗動作です。Auto mode も非対話的に実行されますが、classifier によるブロックが繰り返されると -p セッションが中断されます。そのため、ブロックが発生したジョブは作業が途中まで進んだ状態で失敗します。bypassPermissions は、イメージから再構築するコンテナまたは仮想マシンで使用し、重要な処理も実行するホストでは使用しないでください。

FAQ

Claude Code で auto mode がデフォルトになるのはいつですか？

2026 年 8 月 14 日から、Pro、Max、Team プランの新しいセッションでデフォルトになります。ドキュメントには、モードはいつでも切り替えられること、自分で設定したデフォルトは一度限りの切り替えプロンプトを受け入れない限り維持されること、組織が管理するデフォルトは変更されないことも記載されています。発表では、ロールアウトの初期段階では Enterprise プランと API を使用するアカウントで auto mode は任意のままと説明されています。ステータスバーに ⏵⏵ auto mode on と表示されているか確認すると、セッションで実際に使用されているモードを確認できます。

VPS では auto mode と bypassPermissions のどちらを使用すべきですか？

隔離境界と組み合わせた auto mode を使用してください。分類器は各アクションの実行前に確認しますが、ドキュメントでは、これはアクション単位の制御であり、隔離境界ではないと明記されています。そのため、無人実行ではコンテナ、仮想マシン、または再構築しても問題のない環境を使用してください。bypassPermissions はチェックを完全に省略するもので、隔離された環境でのみ使用するよう記載されています。Claude Code は、Linux で root としてこのモードを開始しようとすると起動を拒否し、--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons を出力します。

サーバー上の全員が auto mode や bypass mode を使用できないようにするにはどうすればよいですか？

permissions.disableAutoMode と permissions.disableBypassPermissionsMode を、/etc/claude-code/managed-settings.json 内で文字列 "disable" に設定してください。管理対象の設定は他のすべてのスコープより優先されるため、ユーザー設定ファイルやコマンドラインフラグで上書きできません。disableAutoMode により Shift+Tab のサイクルから auto が削除され、起動時に --permission-mode auto が拒否されます。disableBypassPermissionsMode はどのスコープからでも使用できるため、単一のユーザーが自身の ~/.claude/settings.json に設定することもできます。

`defaultMode: "auto"` の設定が無視されるのはなぜですか？

設定したファイルが正しくないためです。Claude Code v2.1.142 以降では、defaultMode: "auto" が .claude/settings.json または .claude/settings.local.json から指定されている場合、リポジトリが設定ファイルを配布して自身に auto mode を許可できないように無視されます。セッションは default モードで開始され、エラーは出力されません。設定を ~/.claude/settings.json に移動し、/permissions を実行して、現在有効な各ルールの出所ファイルを確認してください。それでも auto mode を利用できない場合は、モデルの要件を確認してください。Sonnet 4.5 などの古いモデルは、どのプロバイダーでもサポートされていません。

#claude-code #permissions #ai-agents #security #vps