Claude Codeに.envを読ませない設定｜denyで止まらない経路まで塞ぐ【2026年版】

こんにちは、株式会社TIMEWELLの濱本です。Claude Codeを開発に使うチームが増え、「.envを読まれないようにするにはどう設定すればいいのか」という相談をよく受けるようになりました。検索で「claude code .env」と調べてこの記事にたどり着いた方も多いと思います。

先に結論を書きます。

この記事の要点（2026年10月4日時点） Claude Codeに.envを読ませない第一歩は、settings.jsonの permissions.deny に Read(.env) と Read(.env.*) を書くことです。ただし公式ドキュメントによると、このルールが止めるのは、Claude Codeのファイルツールと、catやheadのように対象を名指しするBashのコマンドまで。grep -r のような検索、スクリプトが自分で開くファイル、環境変数の表示は止まりません。そこはサンドボックス（/sandbox）と sandbox.credentials で塞ぎ、念のためPreToolUseフックとコミット前の検査を重ねます。

この半年でClaude Codeの仕様はかなり動きました。初版（2026年5月）で紹介した Write(**/.env*) のような書き方は、いまの仕様では参照されません。macOSとLinuxではファイルの検索がBashのgrepとfindで行われ、対話セッションの既定はautoモードになりました。どれも.envの守り方に直接関わる点です。今回はAnthropicの公式ドキュメント（2026年10月4日確認、最新版はv2.1.288）¹を一つずつ読み直し、設定例を実際に動く形に書き換えました。

設定の前に、チームの誰がどこまでAIエージェントを使っているのかが見えていない場合は、AIリテラシー診断で現在地を確かめておくと、この記事のどこから手を付けるかを決めやすくなります。

Claude Codeから.envが漏れる5つの経路

「.gitignoreに.envを入れた」「CLAUDE.mdに読むなと書いた」で安心している方は多いのですが、前者はコミットを防ぐだけで、後者は強制力を持ちません。公式ドキュメントも「権限のルールを強制するのはClaude Codeであってモデルではない。プロンプトやCLAUDE.mdの指示はClaudeが何をしようとするかを方向づけるが、許可される範囲は変えない」とはっきり書いています²。

2026年4月には、CLAUDE.mdで禁止していたのに .env や .dev.vars の中身が grep -n やReadツールで会話に出てしまった、という報告がGitHubに上がりました³。行番号を出したくて grep -n を打っただけで、一致した行がキーごと表示された、という経緯です。モデルが悪意を持ったわけではなく、デバッグのための自然な一手が漏洩になった例でした。

漏れる経路を整理すると、次の5つに分かれます。

経路	何が起きるか	止める設定
① ファイルツール	Readツール、@ での参照、IDEで開いているファイルの共有	permissions.deny の Read(...)
② 名指しのBashコマンド	cat .env、head、tail、sed など	同上（Claude Codeが認識できるコマンドに限る）
③ 名前を出さない読み取り	grep -r KEY .、スクリプトが自分でファイルを開く	サンドボックスの読み取り禁止
④ 実行時の出力	テストやアプリのログ、エラーにキーが出る	.env.test のダミー値、sandbox.credentials
⑤ 環境変数	env や printenv、子プロセスへの引き継ぎ	sandbox.credentials.envVars、CLAUDE_CODE_SUBPROCESS_ENV_SCRUB

③が見落とされやすいのには理由があります。いまのClaude Codeは、macOS、Linux、WSLではGlobとGrepのツールを既定で持たず、Bashの find と grep で検索します⁴。つまり検索はBashのコマンドとして走り、名指しをしない grep -r にはReadのdenyルールが届きません。

漏れた内容がどこへ行くのかも押さえておきます。Claude Codeが読んだファイルの中身は、会話の一部としてAnthropicのAPI（Amazon BedrockやGoogle Cloudを設定していればその提供元）に送られます。保存期間は、法人向け（Team、Enterprise、API）が標準で30日、個人向け（Free、Pro、Max）はモデル改善への利用を許可していれば5年、許可していなければ30日です。さらに手元の ~/.claude/projects/ に、会話の記録が既定で30日間、平文で残ります⁵。サンドボックスを使っても、Claudeが読んだファイルが送られることは変わりません⁶。読ませないことが一番の対策になるのはこのためです。

permissions.denyで.envの読み取りを止める

最初の一手はdenyルール。設定は5つの層に分かれていて、優先度の高い順に、組織が配る管理設定、起動時の引数、.claude/settings.local.json（個人、プロジェクト単位）、.claude/settings.json（チームで共有）、~/.claude/settings.json（個人、全プロジェクト）と並びます⁷。permissions.deny のようなリストは上書きではなく合算されるので、ホームとリポジトリの両方に書いても、片方が消えることはありません。評価の順番はdeny、ask、allowで、denyに一致したものは、より細かいallowがあっても止まります²。

リポジトリの .claude/settings.json に置く、チーム共有の設定例です。

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(!.env.example)",
      "Read(.dev.vars*)",
      "Read(*.pem)",
      "Read(*.key)",
      "Read(*.p12)",
      "Read(*.pfx)",
      "Read(secrets/**)",
      "Read(~/.aws/**)",
      "Read(~/.ssh/**)",
      "Read(~/.config/gcloud/**)",
      "Read(~/.npmrc)",
      "Bash(printenv *)",
      "Bash(env)",
      "Bash(curl *)",
      "Bash(wget *)"
    ],
    "ask": [
      "Bash(git push *)"
    ]
  }
}

まずは書き方の落とし穴から。Read(.env) のようにファイル名だけを書くと、gitignoreと同じ解釈で、今いるディレクトリより下のどの階層の .env にも一致します。モノレポの奥にある apps/web/.env.local も、Read(.env.*) の1行で止まる計算です。3行目の Read(!.env.example) は除外の指定。同じリストの前にあるルールから、.env.example だけを外します。変数名だけを書いた見本ファイルは、むしろClaudeに読ませたほうが設定ミスの調査がはかどるでしょう。

パスの先頭に付ける記号にも注意が要ります。// で始めると絶対パス、~/ はホームディレクトリ、記号なしは今いるディレクトリからの相対パス。紛らわしいのは先頭が / 1つのときで、こちらは設定ファイルの置き場所が起点になります。ホームの ~/.claude/settings.json に Read(/secrets/**) と書いたら、守られるのはどこでしょうか。答えは ~/.claude/secrets で、プロジェクトの secrets ではありません²。ホーム側には記号なしで書き、どこにあっても止めたいファイルだけを Read(//**/.env) のように書くのが安全です。

初版で紹介した Write(**/.env*) は、いまの仕様では効きません。ファイルの権限はReadとEditのルールだけで判定され、Writeにパスを付けたルールは受け付けられても参照されないためです（v2.1.210以降は起動時に警告が出ます）。代わりにReadのdenyが、同じパスへの編集と新規作成も止めます（編集はv2.1.208以降、新規作成はv2.1.228以降）²。.claudeignore も効果がないと明記されているので、置いている方は中身をdenyルールに移してください。

Bashのルールは補助と考えてください。Bash(curl *) は curl https://... を止めますが、/usr/bin/curl や sh -c 'curl ...' は止めません。公式ドキュメントも、Bashのルールは「セキュリティの境界ではない」と書いています²。ルールは | や && で分割したコマンドごとに照合されるので、初版の Bash(curl * | sh) という形では、ねらった組み合わせを捉えられません。ネットワークの制限は次の節のサンドボックスで行います。

設定を保存したら、Claude Codeで /permissions を開き、ルールとそれを書いたファイルが一覧に出るかを確かめます。そのうえで「.envの中身を見せて」と頼み、設定で拒否された旨が返れば第1層は完成です。

チームの規程に落とし込む方へ: settings.jsonで止められるのは、あくまで技術の層。「どの情報をAIに読ませてはいけないか」を社内のルールとして明文化しておけば、委託先や新しいメンバーにも同じ基準を求めやすくなります。個人情報保護委員会の注意喚起（令和5年6月2日）に沿って、入力してはいけない情報と出力の扱いを全10条の条文にしたひな形を配布しています。→ 生成AI社内導入 稟議書＆利用規程テンプレートをダウンロード（無料。会社名とお勤め先のメールアドレスのご登録が必要です）

denyで止まらない読み取りはサンドボックスで塞ぐ

公式ドキュメントの警告をそのまま引きます。ReadとEditのdenyルールは「Claudeのファイルツール、Bashのcat・head・tail・sed・teeのようにClaude Codeが認識するファイル操作、> file や < file のリダイレクト先に適用される。ファイルを名指しせずに読むコマンド（ファイルのあるディレクトリで実行する grep -r pattern . など）や、PythonやNodeのスクリプトのように自分でファイルを開く子プロセスには適用されない。すべてのプロセスからのアクセスをOSのレベルで止めるには、サンドボックスを有効にする」²。

もう一つ、autoモードの影響も知っておくべきです。v2.1.283以降、対話型のターミナルとVS Codeのセッションは、既定でautoモード（別のモデルが操作を審査し、承認の確認を減らす方式）で始まります。公式の判定順では、作業ディレクトリ内の読み取りは審査に回らず自動で承認されます⁸。denyルールは判定順の最初で効くので、autoモードでも止まります。逆に言えば、denyを書いていなければ、.envの読み取りはだれの目にも触れずに通ります。

サンドボックスは、Claudeが実行するシェルのコマンドと、その子プロセスにOSが制限をかける仕組みです。macOSは標準のSeatbelt、LinuxとWSL2はbubblewrapとsocatを使います（ネイティブのWindowsでは使えません）⁹。セッションで /sandbox を実行すると設定画面が開き、そこで選んだモードはそのプロジェクトの .claude/settings.local.json に保存されます。全プロジェクトで使うなら、ホームの設定に書きます。

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "filesystem": {
      "denyRead": ["~/.aws", "~/.ssh", "~/.config/gcloud"]
    }
  }
}

ここで効いてくるのが、前の節で書いた Read(...) のdenyルール。サンドボックスの読み取り禁止リストにも、自動で足されるからです¹⁰。Read(.env) を書いてサンドボックスを有効にすれば、grep -r もテストランナーも、サンドボックスの中からは .env を開けません。既定のサンドボックスは ~/.ssh や ~/.aws/credentials を含むほぼ全体を読める設定なので⁹、ホームの資格情報は上の例のように明示して閉じます。failIfUnavailable を付けておくと、依存パッケージが足りずにサンドボックスが起動できないとき、黙ってサンドボックスなしで動くのではなく、起動時にエラーで止まります。

効いているかどうかは、手元で確かめるのが一番。公式の手順では、Claudeに touch ~/sandbox-probe を実行させ、Operation not permitted（Linuxでは Read-only file system）で失敗するかを見ます。自分で ! から打ったコマンドは多くの場合サンドボックスの外で動くため、確認になりません。では.envはどう確かめるか。使い捨てのプロジェクトに CHECK_VALUE=not-a-secret のようなダミーだけを書いた .env を置き、Claudeに grep -r CHECK_VALUE . を頼んでみてください。読めずに失敗すれば、狙いどおりです。

サンドボックスの範囲にも限りがあります。対象はBash、PowerShell、Monitorのコマンドだけで、Readなどのファイルツールはdenyルールの担当、フックやMCPサーバーはサンドボックスの外で動きます⁹。2026年8月には、サブエージェントの中で実行した複合コマンドで .env の読み取り禁止が効かなかった、という利用者の報告も出ています（10月4日時点で未解決）¹¹。1つの層に全部を任せず、重ねて使うのが現実的です。

環境変数とテストの出力から漏らさない

サンドボックスの既定では、Claude Codeが持っている環境変数は、そのままコマンドに引き継がれます⁹。Claude Codeを起動したシェルに本番のキーが入っていれば、env 一つで会話に出ます。ここを塞ぐのが sandbox.credentials です。

{
  "sandbox": {
    "enabled": true,
    "credentials": {
      "envVars": [
        { "name": "OPENAI_API_KEY", "mode": "deny" },
        { "name": "STRIPE_SECRET_KEY", "mode": "deny" },
        { "name": "GITHUB_TOKEN", "mode": "deny" }
      ],
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" }
      ]
    }
  }
}

deny を指定した環境変数は、サンドボックスのコマンドが実行される前に外されます⁹。組み込みの禁止リストはないので、守りたい変数を自分で列挙します。もう一つの mask は、コマンドには仮の値を見せ、外へ出る通信のときだけプロキシが本物に差し替える方式です。ログに残るのは仮の値なので④の経路にも効きますが、TLSの終端（network.tlsTerminate）が必要で、ホームの設定、管理設定、起動時の --settings に書いたものしか有効になりません（v2.1.221以降）¹⁰。まずは deny から始めるのが無理のない順番だと考えています。

サンドボックスを使わない場面も含めて広く効かせたいなら、環境変数 CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1 を付けてClaude Codeを起動します。Bashのツール、フック、MCPサーバーの子プロセスから、AnthropicやクラウドのAPIキーなど、Claude Codeが資格情報と認識する変数を取り除きます¹²。

テストの出力にも注意が要ります。「テストを実行して」と頼めば npm test や pytest が走り、接続に失敗したテストが認証ヘッダーごとリクエストをダンプしたり、DBの接続エラーがパスワード入りの接続文字列を表示したりします。Claudeは.envを開いていないのに、キーが会話に乗るわけです。

対策はシンプルで、テストに本物の値を渡さないこと。漏れても困らないダミー値だけを書いた .env.test を用意し、テストの設定で読み込むファイルを .env.test に限定します。複数のファイルを自動で重ねて読む仕組みに任せると、本物の値が混ざりかねないからです。

// vitest.config.ts（.env.test だけを読む）
import { readFileSync } from "node:fs";
import { parse } from "dotenv";
import { defineConfig } from "vitest/config";

export default defineConfig({
  test: {
    env: parse(readFileSync(".env.test")),
  },
});

# conftest.py（.env.test だけを読む）
from dotenv import load_dotenv

def pytest_configure():
    load_dotenv(".env.test", override=True)

.env.test の値は、sk_test_not_a_real_key のように見ただけでダミーとわかる形がおすすめ。本物そっくりの形式で作ると、あとから見た人が本物と見分けにくくなり、レビューのたびに確認の手間が生まれます。

では、根本の対策は何か。本物の値をディスクに置かないことに尽きます。1Password CLIの op run のように実行するときだけ値を注入すれば、.env そのものが要らなくなります。ただし、Claude Codeを起動するシェルに注入してしまうと、子プロセスに引き継がれて⑤の経路に逆戻り。本番の値はClaude Codeのセッションの外で扱う、と決めておくのが一番わかりやすい線引きだと思います。

PreToolUseフックで最後の網を張る

denyとサンドボックスで、大半は止まります。それでも念のための網として、PreToolUseフックを足しておくと安心でしょう。フックはツールが動く前に呼ばれ、標準入力でJSONを受け取り、終了コード2で終われば、その呼び出しを止めます。止めた理由（標準エラーに書いた文）は、そのままClaudeに伝わる仕組みです¹³。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/block-secret-commands.sh",
            "args": []
          }
        ]
      }
    ]
  }
}

#!/bin/bash
# .claude/hooks/block-secret-commands.sh
# Bash から .env 本体を開くコマンドと、環境変数を一覧表示するコマンドを止める
cmd=$(jq -r '.tool_input.command // empty')

# .env / .env.local / .env.production などを名指しするコマンド（.env.example と .env.test は通す）
hits=$(printf '%s\n' "$cmd" \
  | grep -oE '(^|[^[:alnum:]_.-])\.env[[:alnum:]_.-]*' \
  | grep -E '\.env(\.[[:alnum:]_.-]+)?$' \
  | grep -vE '\.env\.(example|sample|template|test)$')
if [ -n "$hits" ]; then
  echo "このプロジェクトでは .env を開くコマンドを止めています。必要な値は人に確認してください。" >&2
  exit 2
fi

# printenv、引数なしの env / export -p / set（環境変数がそのまま会話に出る）
if printf '%s\n' "$cmd" | grep -Eq '(^|[;&|(][[:space:]]*)printenv([[:space:]]|$|[;&|)])|(^|[;&|(][[:space:]]*)(env|export -p|set)[[:space:]]*($|[;&|)])'; then
  echo "環境変数を一覧表示するコマンドは止めています。" >&2
  exit 2
fi

exit 0

スクリプトには chmod +x で実行権限を付け、jq も入れておきます。使ううえで知っておきたい性質は3つ。まず、止めるときは必ず exit 2 にすること。exit 1 は「エラーだが続行」と扱われ、呼び出しは通ってしまいます。次に、フックがタイムアウトしたときも、呼び出しは止まりません。最後に、@ でファイルを指定したときはツールの呼び出しが発生しないので、このフックは動きません。@ の対策は、Readのdenyルールの受け持ちです¹³。

このフックは文字列で判定するだけなので、書き方を変えれば通り抜けられます。だからこそ、Claudeが止められたあと別のコマンドで言い換えようとしたら、その時点で作業を止めて人が確かめる、という運用をチームで決めておくことをおすすめします。フックの仕組み全体はClaude Code Hooks完全ガイドで詳しく扱っています。

スキルを入れるときも、同じ目で見てください。外部のAPIを呼ぶスキルの中には、キーをスキルのフォルダの .env に置く方式のものがあり、そのままだとClaudeが読める場所に鍵を置くことになります。スキル選びの注意点は、Claude Codeおすすめスキル52選の安全面の節にまとめました。

コミット前の検査とチームへの展開

Claude Code側の対策とは別に、人の手で .env やキーをコミットしてしまう事故は起こります。出口で止める仕組みとして、シークレット検出ツールのgitleaksをコミット前に走らせます（最新はv8.30.1、2026年3月21日公開）¹⁴。pre-commitフレームワークを使う場合は、リポジトリの直下に次のファイルを置き、pre-commit install を実行します。

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.30.1
    hooks:
      - id: gitleaks

フレームワークを使わない場合は、.git/hooks/pre-commit に gitleaks git --pre-commit --redact --staged --verbose の1行を書いて実行権限を付けます。検査の対象はステージした変更だけ。見つかったキーは伏せ字で表示されます。.git/hooks はリポジトリで共有されないので、チームで揃えるならpre-commitフレームワークか、CIでの検査（gitleaks-action）を併用します。過去の履歴に残っていないかも、gitleaks git -v で一度洗っておくと安心でしょう。

チームや組織で使うなら、ここまでの設定を一人ひとりに任せず、管理設定（managed settings）で配るのが確実です。管理設定は最優先で、利用者には上書きできません。sandbox.failIfUnavailable を管理設定に入れればサンドボックスなしでは起動しなくなり、permissions.disableBypassPermissionsMode で確認を全部飛ばすモードを禁止でき、allowManagedPermissionRulesOnly で管理側のルールだけを有効にできます¹⁰。無人で長時間動かすなら、Claude Codeのプロセスごと隔離できるdevコンテナや仮想マシンを選びます⁶。組織での使い方の全体像はClaude Codeを組織で使うにはも参考にしてください。

万一読ませてしまったときの手順も決めておきます。会話に出たキーは漏れたものとして扱い、発行元で無効化して差し替えます。消せば済むものではありません。手元の記録は ~/.claude/projects/ に平文で残り、保存期間は cleanupPeriodDays で短くできます。そのセッションを /feedback で送ると記録が5年保存されるので、送らないでください⁵。

こうした基準を社内に根づかせるには、設定ファイルより先に、使う人の理解が要ります。経営層と現場に分けて受講できるAIセキュリティの集中講座として、WARP SECURITYもご用意しています。

2026年5月の初版から変わったこと（当時と現在）

初版から5か月で、設定の前提がいくつも変わりました。初版の設定をそのまま使っている方は、次の表で差分を確かめてください。

項目	初版（2026年5月）	現在（2026年10月4日）
.env の書き込み禁止	Write(**/.env*) を推奨	Writeのパス指定は参照されない。Readのdenyが編集と新規作成も止める
検索の経路	GrepとGlobのツールを前提に説明	macOS、Linux、WSLではBashのgrepとfindが既定。名指ししない検索はdenyの対象外
既定の権限モード	手動承認を前提に説明	v2.1.283以降、対話セッションはautoモードで開始。作業ディレクトリ内の読み取りは審査なしで通る
.claudeignore	言及なし	公式に「効果なし」と明記。denyルールへ移す
環境変数の保護	記載なし	sandbox.credentials の deny と mask、CLAUDE_CODE_SUBPROCESS_ENV_SCRUB
コンテナ	自作イメージで .env を空ファイルに差し替える例	公式のdevコンテナ、sandbox runtime、仮想マシンから脅威に合わせて選ぶ

この半年の流れを振り返ると、問題の指摘が先にあり、仕様が後から追いついてきた印象です。2026年1月には、.claudeignore を置いても秘密のファイルが読まれ、確実に効くのは permissions.deny だけだった、という報道がありました（当時のv2.1.12。記事によると、Anthropicはコメントの依頼に回答していません）¹⁵。いまの公式ドキュメントは .claudeignore が効かないことを明記し、denyルールが効く範囲（Bashのファイル操作やリダイレクト先）と効かない範囲を書き分けています。サンドボックスには資格情報を守る設定も加わりました。

設定の「正解」はこれからも変わります。ここで紹介した書き方も、半年後には古くなっているかもしれません。私は、Claude Codeを更新したら /permissions と /sandbox の画面を開き、起動時の警告を読む習慣を付けるのが一番安上がりな対策だと考えています。受け付けられても参照されないルールは、起動時の警告でしか気づけないからです。

まとめ（今日やる6つのこと）

次のClaude Codeのセッションを始める前に、6つを確かめてください。

1. .claude/settings.json に Read(.env) と Read(.env.*) のdenyルールがあり、/permissions で一覧に出る
2. サンドボックスを有効にし、touch ~/sandbox-probe が失敗することを確かめた
3. 守りたい環境変数を sandbox.credentials.envVars に列挙した
4. テストは .env.test のダミー値だけを読む
5. gitleaksをコミット前とCIで走らせ、履歴も一度洗った
6. 漏れたときにキーを無効化する手順と担当者が決まっている

AIエージェントに開発を任せることは、プロジェクトのファイルを読む新しいメンバーが何人も加わるのと似ています。CLAUDE.mdは「この棚は開けないで」という張り紙、denyルールは棚の鍵、サンドボックスは部屋の鍵、ダミー値は「開けられても中身は空」という備えです。どれか1つではなく、重ねて初めて、安心して任せられるのではないでしょうか。

設定そのものは、半日もかからない作業です。むずかしいのは、それをチーム全員、委託先、これから入る人にまで同じ水準で続けること。その仕組みづくりから相談したい方は、WARPへのご相談からお声がけください。

---

参考文献

Footnotes

1. npm「@anthropic-ai/claude-code」最新版 2.1.288（2026年10月3日更新）https://www.npmjs.com/package/@anthropic-ai/claude-code ↩

2. Anthropic「Configure permissions」Claude Code Docs（2026年10月4日確認）https://code.claude.com/docs/en/permissions ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

3. GitHub anthropics/claude-code Issue #44868「Claude Code exposes secrets from .env / .dev.vars files via grep -n and Read tool, despite CLAUDE.md prohibitions」（2026年4月7日）https://github.com/anthropics/claude-code/issues/44868 ↩

4. Anthropic「Tools reference」Claude Code Docs（2026年10月4日確認）https://code.claude.com/docs/en/tools-reference ↩

5. Anthropic「Data usage」Claude Code Docs（2026年10月4日確認）https://code.claude.com/docs/en/data-usage ↩ ↩²

6. Anthropic「Choose a sandbox environment」Claude Code Docs（2026年10月4日確認）https://code.claude.com/docs/en/sandbox-environments ↩ ↩²

7. Anthropic「Settings files and precedence」Claude Code Docs（2026年10月4日確認）https://code.claude.com/docs/en/settings ↩

8. Anthropic「Choose a permission mode」Claude Code Docs（2026年10月4日確認）https://code.claude.com/docs/en/permission-modes ↩

9. Anthropic「Configure the sandboxed Bash tool」Claude Code Docs（2026年10月4日確認）https://code.claude.com/docs/en/sandboxing ↩ ↩² ↩³ ↩⁴ ↩⁵

10. Anthropic「All settings」Claude Code Docs（2026年10月4日確認）https://code.claude.com/docs/en/settings-reference ↩ ↩² ↩³

11. GitHub anthropics/claude-code Issue #87216「Sandbox file-read deny rule (.env*) not enforced for compound Bash commands in Agent-dispatched subagents」（2026年8月16日、10月4日時点でオープン）https://github.com/anthropics/claude-code/issues/87216 ↩

12. Anthropic「Environment variables」Claude Code Docs（2026年10月4日確認）https://code.claude.com/docs/en/env-vars ↩

13. Anthropic「Hooks reference」Claude Code Docs（2026年10月4日確認）https://code.claude.com/docs/en/hooks ↩ ↩²

14. gitleaks 公式リポジトリ（v8.30.1、2026年3月21日公開）https://github.com/gitleaks/gitleaks ↩

15. The Register「Claude Code's prying AIs read off-limits secret files」（2026年1月28日）https://www.theregister.com/2026/01/28/claude_code_ai_secrets_files/ ↩