何のためのものか
モデル選択・認証・ルーティング・機能トグルを制御する環境変数。同じ挙動は settings のフィールド、CLI フラグ、セッション内コマンドでも設定できることが多い。 だから覚えるべきは変数名の一覧ではなく、どれが勝つかである。
触る
2 通りの設定方法がある。
- シェルで
claudeの起動前に設定する（export/$env:/set）。シェルの環境変数は起動時に読まれるので、変更は次回起動から settings.jsonのenvキーに書く。どのようにclaudeを起動しても有効になる
書式のルールも押さえておく。オン・オフは 1 / true と 0 / false。数値は指数表記と桁区切り（2e3、64_000）も通る。ただし設定されているかどうかだけを見る変数があり、DISABLE_TELEMETRY や CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC は**0 や false を入れてもオンになる**。
入れる
恒常的に効かせたいものを env に移す。置き場所で範囲が決まる。
| ファイル | 適用範囲 |
|---|---|
~/.claude/settings.json | 自分の全プロジェクト |
.claude/settings.json | プロジェクトの全員（ソース管理にコミット） |
.claude/settings.local.json | このプロジェクトの自分だけ |
よく効くものを例に挙げると、待ち時間を延ばす API_TIMEOUT_MS（既定 600000）、長いコマンドを待たせる BASH_DEFAULT_TIMEOUT_MS（既定 120000）と BASH_MAX_TIMEOUT_MS、Bash コマンドの前に毎回走らせる CLAUDE_ENV_FILE（virtualenv や conda の activation を持続させる）あたり。
効かせる
優先順位を機能ごとに確認する。
- 環境変数と専用の settings キーの両方を設定した場合、環境変数が優先される（
ANTHROPIC_MODELはmodelを上書きする） - 同じ変数をシェルと settings の
envの両方に設定した場合、settings ファイルの値が勝つ。 起動時とファイル変更時にenvの各エントリがプロセス環境へ書き込まれ、シェルから継承した値を置き換える - CLI フラグやセッション内コマンドとの関係は機能ごとに違う。
--modelと/modelはANTHROPIC_MODELを上書きするが、CLAUDE_CODE_EFFORT_LEVELは/effortを上書きする。一律の規則は無いので、その機能の記述を見る - settings ファイルでは変数を設定できるが削除はできない。 unset できない変数を打ち消すには
envで空文字列にする
落とし穴
settings.jsonのenvを変更しても、起動時に一度だけ読む機能は再起動まで古い値のまま（OpenTelemetry monitoring など）。ファイルから消しても実行中のセッションでは unset されないCLAUDE_CODE_AUTO_COMPACT_WINDOWは素の整数のみ。500kと書くと500と読まれて 100K に切り上げられる- 通信を止める変数は副作用が広い。
CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFICは feature-flag 取得も止めるため、Remote Control と cross-session messaging が使えなくなる CLAUDE_CODE_SUBPROCESS_ENV_SCRUBは Linux で Bash サブプロセスを分離した PID namespace で動かす。ps/pgrep/killがホストプロセスを見られなくなる- 削除されて no-op になった変数がある（
CLAUDE_CODE_CONNECT_TIMEOUT_MS→API_TIMEOUT_MS）。古い記事の変数が効かないときはこれを疑う