結論：構成・一時directory変数はshellかhostへ移す

Claude Code 2.1.251以降では、project-level .claude/settings.jsonのenvからCLAUDE_CONFIG_DIR、CLAUDE_CODE_TMPDIR、TMPDIR、TMP、TEMPを設定せず、shell、user環境、host、承認済みmanaged settingsへ移します。公式CHANGELOGは、これらをproject envで設定しない変更と、shellで設定する案内を明記しています。

具体的な困りごとは、team共有のproject設定に一時directoryやconfig pathを置いた結果、利用者ごとに存在しないpathへ向かったり、信頼していないrepositoryがClaude Codeの保存先を変えたりすることです。読了後には、共有すべき業務変数と、端末側で管理すべきruntime変数を分けられます。次の行動は、全project settingsのenvを棚卸しし、5変数の有無とownerを記録することです。

この変更はClaude APIの料金を変えません。利用料金は契約plan、model、token、providerに依存します。ただしtmpやconfigの移行を誤るとsession履歴、credential helper、cache、sandbox出力へ到達できず、再試行で利用量が増える可能性があります。新pathへ一括切替せず、読取、書込、権限、容量、cleanup、rollbackを確認します。

project・shell・managedの使い分け

  1. project settings：repository利用者で共有してよいtool設定や安全な業務値に限定します。
  2. shell・user環境：端末固有のconfig directory、一時directory、local pathを管理します。
  3. host・managed settings：企業端末へ統一配布し、利用者が変更すべきでないsecurity boundaryを管理します。
  4. secret manager：API keyや短期credentialをrepositoryへ残さず実行時に注入します。

判断軸は共有範囲、機密性、端末依存、変更owner、監査、失効方法です。projectをcloneした全員が同じ値でよいかが最初の質問です。home path、tmp path、credential locationのように端末依存ならprojectへ置きません。反対に安全なfeature flagでも、個人情報や秘密値を含むならsecret管理へ分離します。

変数名だけを移しても、directoryのownerやmodeが緩ければ安全になりません。Claude Codeを起動するuserが必要範囲だけ読み書きでき、別userやCI jobが不用意に共有しないことを確認します。tmpはsymlink、容量枯渇、cleanup競合もtestし、config directoryはbackup、権限、移行後の旧path残存を確認します。

安全な移行8手順

  1. Claude Code versionと2.1.251の公式CHANGELOGを確認します。
  2. 全repositoryの.claude/settings.jsonをowner付きで棚卸しします。
  3. 対象5変数を抽出し、現在値そのものではなく有無と用途を記録します。
  4. shell、user、host、managed、secret managerの移行先を決めます。
  5. 新directoryを最小権限で用意し、容量とcleanup方針を決めます。
  6. 検証端末一台で新scopeから注入し、project側の指定を外します。
  7. 起動、session保持、tool実行、再起動、cleanupを確認します。
  8. 段階展開し、旧設定と不要directoryを承認後に整理します。

値をlogへ表示して確認しないことが重要です。存在確認、mask済み識別子、pathの親directoryだけで検証し、credentialや個人名をCI logへ出しません。repository変更と端末変更は別commit・別change recordにし、どちらを戻せば復旧するか明確にします。CIではjobごとに専用tmpを割り当て、並列jobの衝突を避けます。

移行後は同じprojectを新しいshellと古いshellで比較し、古い設定へ黙ってfallbackしていないことを確認します。Claude Codeの/statusや/doctorなど利用versionが提供する公式診断を用い、存在しないcommandを推測しません。providerやhostが環境変数を注入する場合は、その管理責任者と更新経路も記録します。

企業展開では端末種別ごとに移行matrixを作ります。macOS、Windows、Linux、container、CI runnerでshell初期化とtmpの扱いが異なるため、一台の成功を全環境の証拠にしません。起動方法がterminal、IDE、Desktop hostで違う場合も、どのprocessが環境変数を継承するかを確認します。

旧directoryを整理する前に、session retentionと監査要件を確認します。移行直後はread-onlyで保管し、rollback期間を過ぎてから承認付きで削除します。共有tmpから秘密が見つかった場合はcredential失効、access log確認、影響範囲の記録を行います。

Platform側の変更はClaude Platform公式release notesでも確認します。

移行チェックリストとHOLD条件

  • versionを確認した
  • 公式CHANGELOGを読んだ
  • 対象5変数を確認した
  • 値をlogへ出していない
  • 各変数のownerがいる
  • 移行先scopeが決まった
  • directory権限を確認した
  • 容量とcleanupを確認した
  • symlinkを確認した
  • 検証端末でtestした
  • rollback手順がある
  • 段階展開した

HOLD条件は、現在値にsecretが含まれる可能性がある、ownerが不明、旧pathを参照するjobを把握できない、権限とcleanupが未確認、全端末へ一括変更しかできない場合です。停止条件は起動失敗、session消失、permission異常、tmp共有、容量警告です。発生時はproject設定へ安易に戻さず、変更recordに従って安全な旧host設定へrollbackします。

よくある質問と次の行動

5変数以外はproject envへ置けますか？

許可されるかだけでなく、共有範囲と機密性を評価します。最新の公式settings文書で制限を再確認してください。

shell profileへ秘密値を書いてよいですか？

平文の恒久保存は避け、secret managerや短期credential helperを利用します。

移行完了は何で判断しますか？

project指定なしで起動・再起動・tool・cleanupが成功し、旧path参照と秘密値露出がないことを確認します。

一次情報はClaude Code公式CHANGELOGとClaude Code公式settings文書です。関連するcredential masking、workspace trust、秘密fileの遮断も確認してください。Miraigentの無料診断では、環境変数の配置scopeを60秒で整理します。