目次
問題: Claude Code は .env を読める
Claude Code はプロジェクトディレクトリ内のファイルを自由に読み取れます。つまり、.env に書いた API キーやデータベースの接続文字列も、指示次第で簡単に読み取られます。
「このプロジェクトの構成を教えて」のような指示でも、Claude Code がコンテキスト収集のために .env を開く場合があります。意図せず秘密情報がセッションに含まれるリスクは現実的に存在します。
.gitignore はあくまで Git の管理対象を制御するものであり、Claude Code のファイルアクセスとは無関係です。Claude Code 側で明示的にブロックする設定が必要になります。
解決策: permissions.deny の設定
プロジェクトルートに .claude/settings.json を作成し、permissions.deny でファイルアクセスを拒否します。
{
"permissions": {
"deny": [
"Read(.env)",
"Read(.env.*)",
"Read(**/.env)",
"Read(**/.env.*)",
"Edit(.env)",
"Edit(.env.*)",
"Edit(**/.env)",
"Edit(**/.env.*)",
"Write(.env)",
"Write(.env.*)",
"Write(**/.env)",
"Write(**/.env.*)"
]
}
}
各ルールの意味
| ルール | 対象 |
|---|---|
Read(.env) |
ルート直下の .env の読み取りを拒否 |
Read(.env.*) |
.env.local, .env.production など接尾辞付きファイルの読み取りを拒否 |
Read(**/.env) |
サブディレクトリ内の .env を再帰的に拒否 |
Read(**/.env.*) |
サブディレクトリ内の接尾辞付きファイルを再帰的に拒否 |
Edit / Write 系 |
同パターンの編集・書き込みを拒否 |
Read だけでなく Edit と Write も拒否している理由は、Claude Code が .env の内容を「編集する」形で読み取る可能性を塞ぐためです。
設定後の動作確認
設定ファイルを配置したら、実際に拒否されるかを確認します。
# Claude Code を起動し、以下を入力する
> .env ファイルの内容を表示して
正しく設定されていれば、Claude Code はファイルへのアクセスが拒否される旨を返します。パーミッションダイアログが表示されず、自動的にブロックされることを確認してください。
追加で、サブディレクトリのケースも試します。
> backend/.env.production の中身を確認して
こちらもブロックされれば、ワイルドカードパターンが正しく機能しています。
既知の制限と注意点
正直に書くと、permissions.deny にはいくつかの不安定な挙動があります。
glob パターンの解釈が一貫しない場合があります。 ** のマッチング挙動は Claude Code のバージョンによって微妙に異なることが報告されています。ルート直下とサブディレクトリの両方のパターンを明示的に書いているのはこのためです。
Bash ツール経由のアクセスは防げません。 permissions.deny は Claude Code のネイティブファイル操作ツール（Read, Edit, Write）を制御します。しかし Bash ツールで cat .env を実行された場合、この設定では防げません。Bash コマンドの制御には別途 Bash(cat .env) のようなパターンを追加する必要があります。
{
"permissions": {
"deny": [
"Read(.env)",
"Read(.env.*)",
"Read(**/.env)",
"Read(**/.env.*)",
"Bash(cat*.env*)",
"Bash(less*.env*)",
"Bash(more*.env*)",
"Bash(head*.env*)",
"Bash(tail*.env*)"
]
}
}
設定の優先順位に注意が必要です。 ユーザーのホームディレクトリにある ~/.claude/settings.json とプロジェクトの .claude/settings.json の両方が存在する場合、両方の deny ルールが統合されます。ただし allow との競合時の挙動は、公式ドキュメントでの説明が限定的です。
検証結果:
実際にキット同梱の settings.json（12パターンの deny ルール）を適用して検証しました。
-
deny 設定後の
.envアクセス: ブロック成功。Claude Code に「.envの内容を表示して」と指示すると、パーミッションダイアログなしで自動的に拒否されました。「このファイルへのアクセスは permissions.deny によりブロックされています」というメッセージが返ります。 -
Bash 経由のアクセス:
Bash(cat*.env*)パターンを追加した場合、cat .envの実行もブロックされました。ただしBash(head*.env*)やBash(less*.env*)も個別に追加する必要がある点に注意してください。パターンは完全一致ではなくワイルドカードですが、コマンド名部分は明示的に書く必要があります。 -
サブディレクトリのマッチ:
backend/.env.productionへのアクセスもRead(**/.env.*)パターンで正しくブロックされました。**のマッチングは期待通りに動作しました。 - バージョン差: 本キットは Claude Code 1.0.x 系で検証しています。glob パターンの解釈が将来のバージョンで変わる可能性はゼロではないため、ルート直下とサブディレクトリの両パターンを明示的に書く冗長な設定にしています。
まとめ
.env の保護は Claude Code を実務で使う上での最低限の安全対策です。permissions.deny は完全ではありませんが、意図しない秘密情報の読み取りリスクを大幅に低減できます。
設定のポイントは3つです。
-
Read,Edit,Writeの3操作すべてを拒否する - ルート直下とサブディレクトリの両方のパターンを明示する
- Bash ツール経由のアクセスも別途ブロックする
この記事で紹介した deny 設定は、導入キットに同梱済みです。12 パターンの deny ルール + セキュリティルール + 実務スキル 10 本がまとめて入っています。.claude/ をコピーするだけで使えます。
※本キットは Anthropic 社の公式製品ではありません。