Claude CodeのdisableAutoMode設定 — auto modeを消す条件と落とし穴
disableAutoMode設定でauto modeをShift+Tabの候補から消す方法と、値の書き方・置き場所・実行中セッションへの反映条件を一次ソースで確認します。
disableAutoModeは、autoモードをShift+Tabの巡回サイクルから完全に取り除く設定キーです。値は"disable"という文字列固定で、trueのような真偽値では効きません。設定できる場所は管理設定に限らず任意のファイルですが、ユーザー自身が上書きできない置き場所は管理設定だけです。
disableAutoMode設定とは — auto modeを選択肢そのものから消す
disableAutoModeは、セッションをautoモードで開始しうるすべての経路を無効化する設定キーです。対象になる開始経路は3つあります。--permission-mode autoのような起動フラグ、defaultMode: "auto"のような設定ファイルの既定値、そしてPro・Max・Teamプランの組み込みの既定値です。これらのいずれかがautoを選ぼうとしても、disableAutoModeが有効なら代わりにdefault(Manualモード)でセッションが始まります。
書き方は次のとおりです。
{
"disableAutoMode": "disable"
}トップレベルのキーとしてだけでなく、permissionsオブジェクトの内側にpermissions.disableAutoModeとして書いても同じ効果があります。他の権限系設定に合わせてpermissions配下にまとめたい場合はこちらを使えます。
TeamプランとEnterpriseプランでは、auto modeの利用そのものが組織に対して既定で許可されています。これに加えてPro・Max・Teamプランでは、新規セッションの既定の開始モード自体がauto modeになるため、開発者が何も設定しなくても最初からauto modeで動き始めます。組織としてこの状態を止めたい場合に公式に用意されているopt-out手段が、管理設定へのdisableAutoModeの設定です。
効果が及ぶのはCLIのターミナルセッションだけではありません。VS Code拡張・JetBrainsプラグイン・デスクトップアプリ・Agent SDKセッションもすべて同じ管理設定ソースを読むため、disableAutoModeを管理設定に置けば組織全体のセッションからautoが一律で消えます。Amazon Bedrock・Google CloudのAgent Platform・Microsoft Foundry経由のセッションでも、Shift+Tabの巡回サイクルからautoを取り除く効果は同じです。一方でClaude DesktopのCoworkタブは対象外です。Coworkは独自の権限モード体系を別に持っており、CLIやVS Code拡張が使うこのauto modeの仕組みとは切り離されています。
設定できる場所と、実際に効く場所
設定リファレンスでのdisableAutoModeのScopeはAny file(任意のファイル)です。allowManagedPermissionRulesOnlyのように管理設定以外からは無視される、管理設定専用のキーではありません。ユーザー設定・プロジェクト設定・ローカル設定のどこに書いても値そのものは反映されます。
ただし「反映される」ことと「開発者が自分で外せない」ことは別問題です。設定の優先順位は次の順で、上にあるファイルほど強くなります。
| 優先順位 | 置き場所 | 開発者本人が上書きできるか |
|---|---|---|
| 1(最強) | 置き場所管理設定(managed-settings.json / MDM / server-managed) | 開発者本人が上書きできるかできない |
| 2 | 置き場所コマンドライン引数(--settings) | 開発者本人が上書きできるか管理設定より弱い |
| 3 | 置き場所プロジェクトローカル設定(.claude/settings.local.json) | 開発者本人が上書きできるか本人が書けば上書きできる |
| 4 | 置き場所共有プロジェクト設定(.claude/settings.json) | 開発者本人が上書きできるかローカル設定で上書きできる |
| 5(最弱) | 置き場所ユーザー設定(~/.claude/settings.json) | 開発者本人が上書きできるか上位のどれかがあれば負ける |
チームの共有.claude/settings.jsonにdisableAutoMode: "disable"を書けば、そのリポジトリで作業する全員のセッションはManualで始まります。管理者権限がなくても、リポジトリを触れる立場であれば設定できるという点は見落とされがちです。ただし、この置き場所は.claude/settings.local.jsonという自分専用ファイルの方が優先順位が高いため、各自の環境でその上書きを消せば効果を無効化できてしまいます。組織として本当に外せなくしたいなら、管理設定に置くのが唯一の方法です。設定リファレンスのallowManagedPermissionRulesOnlyのように「管理設定でしか設定できない」キー一覧にdisableAutoModeは含まれていないため、この違いは値そのものではなく置き場所の優先順位で作られています。
設定すると何が起きるか — 起動時と実行中セッション
新規セッションに対しては、disableAutoModeが有効な間、autoはShift+Tabの巡回に一切現れません。--permission-mode autoを明示しても、組み込みの既定値がautoを選ぼうとしても、そのセッションはdefault(Manual)で始まります。
claude --permission-mode autodisableAutoModeが管理設定で有効な環境では、上記のコマンドを実行してもManualモードで起動します。エラーにはならず、静かにフォールバックする点に注意が必要です。
すでにautoモードで動いている実行中のセッションについては挙動が分かれます。管理設定側からこの値が届いたセッションは、そのタイミングでautoモードを離れ、auto mode disabled by settingsというメッセージを表示します。v2.1.251より前のバージョンでは、この即時反映がなく、実行中のセッションはそのまま終了するまでautoモードを維持していました。古いバージョンを使っている環境では、設定変更後もセッションを開き直すまで反映されない点を覚えておく必要があります。
defaultModeやallowManagedPermissionRulesOnlyと何が違うか
名前の似た権限系設定ほど、制御する対象を取り違えやすくなります。
| 設定キー | 制御する対象 | 個人設定で上書きできるか |
|---|---|---|
disableAutoMode | 制御する対象autoモードという選択肢自体の有無 | 個人設定で上書きできるか管理設定にあれば不可 |
permissions.defaultMode | 制御する対象新規セッションの開始モード(auto以外も指定可) | 個人設定で上書きできるかプロジェクト・ローカルでも設定可能 |
allowManagedPermissionRulesOnly | 制御する対象allow/ask/denyルールの読み込み元 | 個人設定で上書きできるか管理設定専用キー |
useAutoModeDuringPlan | 制御する対象Plan mode中にauto modeの分類器を使うか | 個人設定で上書きできるか一部の値は例外的に強い優先順位を持つ |
permissions.defaultModeだけを"default"に設定しても、それは「既定の開始モード」を変えるだけです。ユーザーがShift+Tabや--permission-mode autoを使えばautoへ戻れてしまいます。autoという選択肢自体を消すにはdisableAutoModeが必要で、この2つは重ねて使う前提の別レイヤーの設定です。
useAutoModeDuringPlanは毛色が異なり、Plan mode中にシェルコマンドを分類器でレビューするかどうかを決めるだけの設定です。ここでfalseを管理設定・--settings・~/.claude/settings.json・.claude/settings.local.jsonのいずれかに置くと、より強い優先順位を持つ管理設定のtrueがあってもfalse側が勝つという例外的な扱いを受けます。disableAutoModeにはこの種の例外はなく、通常の優先順位スタックがそのまま適用されます。
設定が届いているか確認する
disableAutoModeを管理設定に置いても、配信の仕組み上すぐに全端末へ反映されるとは限りません。ファイルベースの管理設定は起動時とファイル変更時に読み込まれ、MDMやserver-managed設定は起動時に加えて一定間隔のポーリングで更新されるため、反映までタイムラグが生じることがあります。
/statusdisableAutoModeのような一般的な管理設定が実行中のセッションに届いているかどうかは、/statusのSetting sources行で確認します。ここにはどの管理設定ソースが読み込まれたかが表示されます。claude doctorのOrganization policy行は、これとは別にRemote Control・Webセッション向けの組織設定を診断するためのもので、disableAutoModeを含む一般のmanaged settingsの到達確認には使えません。disableAutoModeを配布したのに一部の端末だけautoが選べてしまう場合は、/statusのSetting sources行でポリシーが届いているかどうかを見ます。
auto modeそのものが利用不可と表示される場合も、原因の一つとしてdisableAutoModeを疑う価値があります。プラン・モデル・プロバイダーの利用条件をすべて満たしていても、どこかの設定ファイルがdisableAutoModeを設定していればautoは選択肢に出てきません。他の原因も含めた切り分け方はauto modeがShift+Tabで有効化できない原因と対処法で確認できます。
よくあるつまずき
trueや1を書いて効かない: 受け付ける値は文字列"disable"だけです。真偽値のつもりでtrueと書いても仕様上は無視されます- 無効化したつもりが個人設定にしか書いていない:
~/.claude/settings.jsonや自分の.claude/settings.local.jsonに書いても、それは自分のセッションにしか効きません。チーム全体・組織全体に強制したい場合は共有設定または管理設定に置く必要があります - 共有プロジェクト設定に書いたのにチームメイトの一部で効かない:
.claude/settings.local.jsonは共有プロジェクト設定より優先順位が高いため、そのメンバーが個人のローカル設定で打ち消している可能性があります。組織として確実に固定したいなら管理設定に上げる必要があります permissions.disableBypassPermissionsModeと混同する: 名前は似ていますが、こちらはbypassPermissionsモードそのものを禁止する別の設定です。--dangerously-skip-permissionsを拒否する効果はありますが、autoモードには影響しません- 古いバージョンでBedrock・Foundry経由の実行中セッションに反映されない: v2.1.251より前は、管理設定の変更が実行中セッションに即時反映されず、セッション終了まで
autoモードが残ります。反映を急ぐ場合はセッションを再起動します
まとめ
disableAutoModeは、autoモードという選択肢そのものをShift+Tabの巡回・起動フラグ・組み込みの既定値のすべてから取り除く設定です。値は文字列"disable"固定で、置き場所はAny fileという広いスコープを持ちますが、開発者本人が上書きできない強制力を持つのは管理設定に置いたときだけです。プロジェクトの共有設定に置く運用は手軽ですが、.claude/settings.local.jsonで個々に打ち消せる点は把握しておく必要があります。組織としてauto modeそのものを封じたい管理者と、単に自分のセッションだけ手動に戻したい開発者とでは、選ぶべき設定もその置き場所も変わってきます。Shift+Tabでの一時的な切り替えやpermissions.defaultModeによる開始モードの変更を含めた手動運用への戻し方はClaude Codeの自動承認オフ — 手動モードに戻す手順にまとめています。auto modeがそもそもどの条件で既定になるのかはauto mode既定化で確認したい設定、allow/ask/denyルールを含めた権限管理全体はClaude Codeの/permissionsコマンドで権限ルールとauto mode拒否を管理する、分類器が実際に何を止めているかはauto modeブロック一覧 — 既定で何を止めるかで確認できます。