Claude Media
CLAUDE_CODE_ENABLE_AUTO_MODEとは — auto modeの有効化と、不要になった条件

CLAUDE_CODE_ENABLE_AUTO_MODEとは — auto modeの有効化と、不要になった条件

auto modeでCLAUDE_CODE_ENABLE_AUTO_MODEを求められたときの対処。環境変数の書き方、v2.1.207で不要になった条件、設定が効かないときの見どころを扱います。

CLAUDE_CODE_ENABLE_AUTO_MODE=1 は、Bedrock・Vertex AI・Foundry経由でauto modeを使うためのオプトイン用の環境変数でした。v2.1.207以降は不要です。公式docsにも、互換性のために受け付けるが効果はない、とあります。auto modeを選ぼうとして環境変数を求める案内が出たなら、最初に見るのは環境変数ではなくClaude Codeのバージョンです。

環境変数の役割と、不要になるまでの経緯

auto modeは、--permission-mode で選べる6つの権限モードのひとつです。ツール呼び出しのたびに人へ確認を求める代わりに、分類器モデルが安全性を判定して自動承認します。設計思想はClaude Code auto modeの中身で扱いました。

この環境変数の出番は、Anthropic APIの直接認証ではない構成にありました。次の流れで役割が変わっています。

あゆみ

環境変数が必要だった期間

  1. v2.1.1583プロバイダーでauto modeが解禁

    当初の対象はOpus 4.7とOpus 4.8で、CLAUDE_CODE_ENABLE_AUTO_MODE=1 で明示的にオプトインする仕様でした。環境変数がないと、defaultMode: "auto" も無視されます。

  2. v2.1.160利用不可メッセージの修正

    モデルのせいだと読める案内が改められ、環境変数によるオプトインを指す文言になりました。検索でたどり着く読者が見るのは、多くの場合この案内です。

  3. v2.1.207オプトインが不要に

    3プロバイダーで環境変数なしにauto modeが使えます。無効化する側は disableAutoMode に一本化されました。

  4. v2.1.283サードパーティ構成の既定がauto modeに

    changelogでは、サードパーティプロバイダーかテレメトリー無効の対話セッションが、権限モード未設定ならauto modeで始まる変更です。

  5. v2.1.284全プラン・全プロバイダーに拡大

    ターミナルとVS Codeの対話セッションが、権限モード未設定ならauto modeで始まります。

v2.1.158とv2.1.207の個別の変更はv2.1.158の解説とv2.1.207の解説にあります。

案内が出て進めないときの切り分け

環境変数を立てる前に、次の順で見ると原因に早く当たります。

手順

auto modeが選べないときの確認順

  1. 1

    バージョンを確認する

    v2.1.207以降なら、3プロバイダーのいずれでも環境変数は要りません。更新で案内が消えるかを先に試します。

  2. 2

    モデルが対象か確かめる

    Bedrock・Vertex AI・Foundryでは、Sonnet 5以降、Opus 4.7以降、Fableモデルが対象です。Sonnet 4.5やHaikuなど、それより古いモデルはどのプロバイダーでも使えません。

  3. 3

    disableAutoModeを探す

    どの設定ファイルであれ、permissions.disableAutoMode が "disable" ならauto modeは出てきません。管理設定に置かれていると、手元の設定では上書きできません。

  4. 4

    設定の置き場所を見直す

    defaultMode: "auto" や autoMode ブロックを、リポジトリ内の設定ファイルに書いていないかを確認します。後述のとおり、その場所は読まれません。

バージョンの確認と更新

claude --version
claude update

v2.1.210では、オプトインの要らなくなったプロバイダーで /doctor がauto modeを既定にする提案を飛ばしていた問題も直りました。診断結果の食い違いは、更新で解消します。

v2.1.206以前に固定している場合

社内でバージョンを固定していて更新できないなら、環境変数でオプトインします。

export CLAUDE_CODE_ENABLE_AUTO_MODE=1
claude

v2.1.158から206の間は、この変数がないと defaultMode: "auto" も効きませんでした。シェルの設定ファイルに書くと、auto modeを使わないセッションにも影響します。

書き場所効く範囲向くケース
シェルの設定ファイル効く範囲その端末の全セッション向くケース個人の常用環境
settings.json の env効く範囲設定ファイルのスコープ内向くケースプロジェクト・組織単位で揃える
CI・起動スクリプトの環境変数効く範囲そのジョブのみ向くケース非対話実行、コンテナ

settings.json に書く場合は次の形です。ユーザー設定なら ~/.claude/settings.json、プロジェクト共有なら .claude/settings.json に置きます。

{
  "env": {
    "CLAUDE_CODE_ENABLE_AUTO_MODE": "1"
  }
}

設定ファイルの階層と優先順位はClaude Code設定ガイドに一覧があります。

設定したのに効かないのは、置き場所のせいかもしれない

環境変数を立てても変わらないとき、原因が書き方より置き場所にあることがあります。公式docsに、次の制約があります。

  • defaultMode: "auto" はリポジトリ内の設定では無効です。.claude/settings.json と .claude/settings.local.json に書いても効きません。~/.claude/settings.json の値も使われず、組み込みの既定になります
  • autoMode ブロックも同じで、v2.1.207以降は .claude/settings.local.json から読まれません。チェックイン済みのリポジトリやビルド手順が、自前の許可ルールを紛れ込ませられないようにするためです
  • bypassPermissions も同様に、この2つのファイルでは無視されて、セッションはManualで始まります

ターミナルの外では扱いが違います。VS Code拡張は、起動時の権限モードにプロジェクトの設定ファイルを読みません。

auto modeが使えない条件(モデルが非対応、設定ファイルで無効化、Anthropic側でのサーバー側停止)のときは、Manualで始まります。何も表示されずにManualになる典型は、前述のプロジェクト設定に defaultMode: "auto" を置いた場合です。サーバー側で拒否された場合、そのセッションが終わるまでauto modeは戻りません。

権限モードを設定しないと何で始まるか

公式のモード解説では、v2.1.283以降、ターミナルとVS Code拡張の対話セッションは、権限モードを何も設定していなければauto modeで始まります。changelogでは、全プラン・全プロバイダーへの拡大がv2.1.284の項目で、バージョンが1つずれています。それ以前は、Pro・Max・Teamプランで機能フラグを取得できるセッションだけがauto modeで、ほかはdefaultでした。

claude -p とAgent SDKは扱いが違います。機能フラグを取得するセッションではdefaultで始まります。サードパーティプロバイダーやテレメトリー無効のセッションは、v2.1.285以降でauto modeで始まります。

起動時のモードを自分で決めるなら、--permission-mode か permissions.defaultMode を使います。組織全体でauto modeを外すなら、管理設定の permissions.disableAutoMode を "disable" にします。この指定は Shift+Tab の切り替えサイクルからauto modeを外し、--permission-mode auto で起動してもManualで始まります。

実機で確認できるauto modeの設定コマンド

v2.1.286で、auto modeの設定を確かめるサブコマンドを確認しました。--help の出力は次のとおりです。

claude auto-mode --help
Commands:
  config              Print the effective auto mode config as JSON: your
                      settings where set, defaults otherwise
  critique [options]  Get AI feedback on your custom auto mode rules
  defaults [options]  Print the default auto mode environment, allow, soft_deny,
                      and hard_deny rules as JSON
  help [command]      display help for command
  reset [options]     Reset auto mode configuration to the shipped defaults by
                      removing the autoMode section from your user settings file

config は、設定した箇所は設定値、それ以外は既定値を合わせた実効の設定を出します。設定が反映されたかは、ここで確かめるのが確実です。reset はユーザー設定ファイルの autoMode セクションを消して既定に戻すコマンドで、-y か --yes で確認を省けます。

既定のルールの数も出力から数えられます。

claude auto-mode defaults | jq -c 'map_values(length)'
{"allow":17,"soft_deny":72,"hard_deny":1,"environment":21}

v2.1.286の既定では、hard_deny は1件だけです。内容はデータの持ち出しに関するルールで、信頼する宛先の外へ機密データを出す操作を、依頼があっても止めます。止める範囲の大半は72件の soft_deny で、一覧はauto modeブロック一覧にまとめています。--label に接頭辞を渡すと、そのラベルのルールだけに絞れます。

有効にしたあと、何が止まり何が通るか

auto modeはすべてを素通しにしません。分類器が呼び出しごとに評価し、危険と判断したものだけをブロックします。ブロックされた操作は通知が出て、/permissions の最近の拒否一覧に残り、r で手動承認つきの再試行もできます。--dangerously-skip-permissions との違いはここです。分類器が3回連続、または累計20回ブロックすると、auto modeは一時停止して確認プロンプトに戻ります。プロンプトされた操作を承認すると再開します。この回数は変更できません。権限モード全体の比較はClaude Codeセキュリティ・権限ガイドで扱っています。

調整は settings.json の autoMode で行います。

フィールド役割
environment役割自組織のリポジトリや内部ドメインなど、信頼する範囲を宣言する
allow役割分類器の止めるルールに対する例外を指定する
soft_deny役割原則止めるが、明示的な依頼があれば通す操作
hard_deny役割ユーザーの意図や allow を問わず無条件でブロックする操作(v2.1.136で追加)

落とし穴は、4つのどのセクションも "$defaults" を含めずに書くと、そのセクションの既定を丸ごと置き換えることです。allow と soft_deny だけの話ではありません。既定を残して足すときは、配列に "$defaults" を入れます。

{
  "autoMode": {
    "soft_deny": [
      "$defaults",
      "自組織の本番クラスターに対するkubectl deleteは依頼があっても止める"
    ]
  }
}

このJSONは ~/.claude/settings.json か管理設定に置きます。保存したら claude auto-mode config で、追加した行が実効の設定に入っているかを確かめます。各セクションは独立して評価されるので、environment だけを書いても、ほかの3つの既定は残ります。

誤検知が続くときは、environment の記述不足が先に疑われます。公式docsは、まず自組織のソース管理と主要な内部サービスを足し、次に信頼するドメインとクラウドバケットを足す順序を挙げています。リポジトリへのpushが止まる、といった典型的な誤検知は、前者で片づくとされています。

判定の範囲も広がってきました。v2.1.193では autoMode.classifyAllShell が加わり、任意コード実行のパターンだけでなく、Bash・PowerShellの全コマンドを分類器に通せます。同じ版で、拒否の理由が会話の記録・拒否時の通知・/permissions の最近の拒否一覧に残るようになりました。

破壊的な操作への線引きも固くなっています。v2.1.183では、git reset --hard や git stash drop が、頼んでいない限りブロックされます。git clean -fd や terraform destroy も同じ扱いです。v2.1.208では、rm -rf ~ のような削除が $(…) やバッククォートに埋まっていても、確認が出るようになりました。

外部向けのセッションで使う分類器は、v2.1.210から既定でSonnet 5になりました。セッション最初のリクエストで検証して、セッションに固定されます。

分類器の呼び出しは何を消費するか

auto modeの判定は、ツール呼び出しごとに分類器へ問い合わせる往復を伴います。公式docsによると、Enterpriseプランでは分類器の呼び出しがトークン使用量に数えられます。Claude API・Claude Platform on AWS・Amazon Bedrock・Google Cloud・Microsoft Foundryのアカウントも同じです。1回の確認で、会話の一部と実行しようとしている操作が送られます。

もっとも、作業ディレクトリ内の読み取りと、保護対象でないパスへの編集は分類器を通りません。往復が増えるのは、主にシェルコマンドとネットワーク操作です。サーバー側で操作を審査する構成では、分類器の呼び出しが別枠で発生しないので、数えるものもありません。

分類器が判定できないときの挙動も押さえておく価値があります。サーバー側で操作を審査する構成では、判定を返さなかった操作は拒否されます。拒否の前に待機が入ることがあり、対話セッションではスピナーに Auto mode check unavailable とカウントダウンが出ます。10回連続で判定が得られないとターンが止まり、Auto mode is unavailable で始まるメッセージが出ます。止まった原因は、/permissions の最近の拒否一覧で追えます。

Bedrockでは、分類器が呼ぶモデルをアカウントが呼べないと、同じエラーが繰り返されることがあります。メッセージに cannot determine the safety を含むものは、分類器の要求が失敗したときの文言で、多くは一時的です。繰り返すときは、メッセージが名指ししたモデルの利用権限を先に確かめます。

自分で書いたルールの出来が気になるときは、claude auto-mode critique が役に立ちます。独自ルールについて、AIからの指摘を受け取るコマンドです。--model でどのモデルに見せるかを選べます。実行するとモデルへの問い合わせが発生します。

ほかに疑う点

  • プランモード:auto modeが使えて useAutoModeDuringPlan がオンなら、プランモード中のシェルコマンドも分類器が見ます。既定でオンです。オフにすると、組み込みの読み取り専用コマンドを除いて確認が出ます
  • OAuthトークンの失効:セッション途中でトークンが失効・ローテーションすると、auto modeが「HTTP 401」の分類器エラーでコマンドを拒む問題がありました。v2.1.216で修正されています

まとめ

v2.1.207以降のBedrock・Vertex AI・Foundryでは、CLAUDE_CODE_ENABLE_AUTO_MODE を立てる必要はありません。案内が消えないときは、バージョン、モデル、disableAutoMode、設定の置き場所の順に見ます。環境変数を立てるのは、v2.1.206以前に固定している環境だけです。

Claude Code全体の設定と権限の地図はClaude Codeとは — できること・料金・使い方にあります。

この記事を共有:XはてブLinkedIn