Claude Code に .env を読ませない — deny permissions の現実とフックでの実効的対策

Claude Code の `settings.json` で `deny` permissions を書けば `.env` を保護できる、と思っているなら危険。Anthropic 公式リポジトリには 2026 年に入っても deny ルールが Read/Bash で正しく強制されないバグ報告が複数残っており、The Register も 2026 年 1 月に報じた。本稿は現実的に「秘密情報を Claude に読ませない」ための実装手順をまとめる。

何が壊れているか

公式ドキュメント上の推奨設定はこう書く：

{
  "permissions": {
    "deny": ["Read(./.env)", "Read(./.env.*)", "Read(*.pem)", "Read(*.key)", "Read(~/.ssh/**)"]
  }
}

しかし `anthropics/claude-code` の Issue（#6699 / #8031 など）と The Register の検証（2026-01-28）では、deny に設定したパターンが Read / Bash の `cat` などで素通りしてしまうケースが報告されている。最悪のシナリオは「auto-approve モードで `cat .env` が走り、コンソールに表示された秘密情報がそのままセッションログ／クラウド送信される」というもの。

現実的に効く対策（多層防御）

1. PreToolUse フックで強制ブロック

Claude Code のフックはシェルコマンドが**確実に走る**決定論的仕組みで、permissions のバグの影響を受けない。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Read|Bash",
        "command": "node ~/.claude/hooks/block-env.js"
      }
    ]
  }
}

フック側で tool 引数を見て `.env` / `.pem` / `*.key` を含めば exit 1（ブロック）。コミュニティ実装 `li-zhixin/claude-ignore` も同じ思想。

2. Sandboxing で OS レベル分離

`/sandbox` を有効化し、`.env` を含むディレクトリを `denyRead` に入れる：

{
  "sandbox": {
    "enabled": true,
    "filesystem": { "denyRead": ["./.env", "./.env.*"] }
  }
}

OS（macOS Seatbelt / Linux bubblewrap）レベルで `cat .env` などサブプロセスの読み取りも止まる。**ただし Sandbox は Bash 系のみ対象**。Read/Edit/Write は permissions のレイヤで別途守る必要がある。

3. そもそも `.env` に重要な秘密を置かない