Claude Codeのdenyが効かない？.envを守る権限設定と10日で12版の修正

sh -c "rm -rf <作業ディレクトリ>" と書くだけで、確認ダイアログが出ないままファイルが消えた（rm -rf はフォルダを丸ごと消すコマンド、sh -c は文字列をシェルに渡して実行する書き方だ）。

2026年9月23日、Claude CodeのGitHubリポジトリに立ったIssue #96300の報告者は、同じ削除コマンドを6通りの書き方で3〜5回ずつ試している。素の rm -rf やサブシェル ( )、$( ) で包んだ形はすべて「Dangerous rm operation detected」で止まった。止まらなかったのは sh -c と bash -c で包んだ2つだけだ。報告者は次の趣旨を書いている（筆者訳・要約）。「bypassモード（確認ダイアログを省略してClaudeに作業を任せる設定）では、このチェックが作業ディレクトリやホームディレクトリの削除前に出る唯一の確認だ。sh -c を1枚かぶせるだけで、その確認が消える」。

この穴は2.1.288で塞がれた。ただ、これは氷山の一角にすぎない。9月30日から10月10日（日本時間）までの約10日間に、Claude Codeは2.1.285から2.1.296まで12のバージョンを出し、その変更履歴には権限ルール・サンドボックス・フック絡みの修正がずらりと並んだ。

結論から書く。denyルールは「うっかり防止の柵」であって、秘密情報を守る「壁」ではない。 やることは3つだ。2.1.296以降に更新する、/permissions でdenyルールが読み込まれているか確かめる、/sandbox でサンドボックスを有効にする。設定例は記事後半にまとめた。

Claude Codeのdenyをすり抜けた主な修正（2.1.285〜2.1.296）

公式のCHANGELOGから、denyルールや確認ダイアログが効かなかったケースを抜き出すとこうなる。全部読む必要はない。bypassモード、自作フック、Windowsなど、自分の使い方に当てはまる行だけ見ればいい。

バージョン	修正内容（要約）
2.1.285	PowerShellのコマンド解析が起動に失敗したとき（メモリ不足など）、deny/askルールの判定を飛ばし、その失敗をキャッシュしていた
2.1.288	bash -c / sh -c 内の危険な rm が、bypassモードやシェルのallowルール下で確認なしに走っていた（#96300）
2.1.288	PreToolUseフックのマッチングに失敗した場合などに、フックがスキップされていた。現在はツール呼び出し自体をブロック
2.1.289	TZ="$HOME" rm -rf build のような環境変数プレフィックス付きコマンドが、サンドボックス自動許可時にdeny/askルールをすり抜けていた
2.1.289	IDEでシンボリックリンク経由で選択・@メンションしたファイルに、Readのdenyルールが効いていなかった
2.1.290	rg や git grep など読み取り専用扱いのコマンドが、シェルがワイルドカード展開する引数でも自動承認されていた
2.1.290	PreToolUseフックが入力を書き換えた後、一部の権限ルールと安全チェックが適用されていなかった
2.1.292	「Security」と明記された修正。PreToolUseフックの承認とauto modeが、ネットワーク（UNC）パスからの読み取りで確認をスキップしていた
2.1.292	macOS/Windowsで、読み取りの途中にリンクを差し替えると、承認範囲外のノートブックやPDFを返し得た
2.1.296	Windows（Git Bash）で rm -rf /c/Users/<name> がbypassモードで確認なしに通っていた

denyルールの穴は今回が初めてではない。2026年4月にも、50個以上のサブコマンドを連ねるとdenyルールが無効になる脆弱性がv2.1.90で修正されている（当時の解説記事）。

並べてみると、パターンははっきりしている。ルールが見ているのは「Claudeが書いたコマンドの文字列」で、同じ操作を別の書き方でやられると取りこぼす。シェルで包む、変数を前に置く、リンクを挟む、Windowsのパス表記にする。どれも人間の攻撃者でなくとも、モデルが普通の作業の中で書きうる形だと自分は考えている。

PMとしてこの表を見たとき、まず思ったのは「品質が悪い」ではなかった。ここまで細かい抜け道がほぼ毎日のように潰されているのは、外部からの報告と開発側の修正がかなりの密度で回っているからだろう、と受け止めた。気になったのは別の点で、これだけ直してもなお、公式ドキュメントや変更履歴のどこにも「穴がゼロになった」とは書かれていないことだ。

denyルールを書いても.envが読まれる理由（公式が認める限界）

Claude Codeの権限設定のドキュメントには、denyルールについてかなり率直な記述がある。

a deny or ask rule covers the invocation Claude usually produces and isn’t a security boundary around the program.

（2026年10月11日確認。引用は原文のまま、以下の要約は筆者による）

要するに、Bashのdenyルールは「Claudeがふだん書く形」を止めるものであって、そのプログラムを囲む防壁ではない、ということだ。ファイルについても同様で、ReadやEditのdenyルールは組み込みファイルツールと cat・head・sed などClaude Codeが認識するコマンドには効くが、PythonやNodeのスクリプトが自分でファイルを開く場合や、grep -r pattern . のようにファイル名を名指ししない読み取りには効かないと明記されている。

もうひとつ、地味だが効く一文がある。.claudeignore ファイルは効果がないので、中身をReadのdenyルールに移せ、という記述だ。

2026年1月、The Registerは「Claude Codeが.claudeignoreや.gitignoreを無視して.envを読む」と報じた。記事によれば、Claude自身に防ぎ方を聞くと「.claudeignoreに.envを書けば、.gitignoreのように読み込みを拒否します」と答えたという。AIが自分の仕様を間違えて説明し、それを信じたユーザーの秘密情報が意図せず読まれてしまう。この構図には一番注意したい。

ユーザーが踏んだ地雷

書式の罠。 2026年2月のIssue #24846では、報告者が **/.env* や **/.ssh/** をdenyに並べたのに .env.local の中身（APIキーや認証情報）がそのまま表示されたと書いている。ただ、そこに貼られた設定は permissions.read.deny という形で、公式ドキュメントの permissions.deny に Read(./.env) を並べる書式とは異なる。issueは既存の報告の重複としてクローズされたが、「書いたつもりの設定がそもそも効いていなかった」可能性は誰にでもある。2.1.210で Write(path) などマッチしないルールに起動時の警告が出るようになったのも、同じ種類の事故への対策だ。対処は /permissions で読み込み状況を目で確かめることに尽きる。

経路の罠。 DEV Communityでdeny-probeというツールを公開したhao li氏は、Read(./.env) を1行だけ書いた状態で12の読み出し経路を試し、氏の環境では10経路で中身が読み取れたと報告している（筆者は再現していない）。タイトルは「あなたのRead denyルールは網戸だ」。同記事は、別の投稿者が claude -p を20セッション走らせて11経路中4経路が素通りしたという検証にも触れている。denyの及ばない経路は、後述するサンドボックスの denyRead で補うしかない。

ラッパーの罠（未解決）。 9月7日（日本時間）に立ったIssue #92542は、Bashのdenyルール判定の前に剥がされるラッパーが timeout、nice、nohup など8種類の固定リストしかなく、それ以外の「引数をそのまま実行する」プログラムを挟むとdenyもallowも参照されないと指摘している。本記事執筆時点（10月11日）でこのissueはオープンのままだ。未解決である以上、重要なパスはサンドボックス側で守る前提に立つ。

削除の罠。 2025年12月には、rm -rf tests/ patches/plan/ ~/ という末尾に ~/ が紛れ込んだコマンドでMacのホームディレクトリがほぼ消えたとGIGAZINEなどが報じ、Redditでも大きな話題になった。権限確認をスキップしていたか、よく読まずに承認した可能性が指摘されているが、詳細ははっきりしていない。承認前にコマンドの末尾まで読む。基本だが、これが一番効く。

もちろん光の面もある。Anthropicは2025年10月のエンジニアリングブログで、OSレベルのサンドボックスにより社内利用で権限プロンプトを安全に84%減らせたと書いている。確認ダイアログを減らしつつ安全性を上げる道具は、すでに手元にある。

自分ならこう設定する：.envを守るdeny＋サンドボックス

ここからは電脳狐影としての判断だ。自分はdenyルールを「うっかり防止の柵」、サンドボックスを「壁」と割り切って、両方を重ねる。

~/.claude/settings.json の例はこうなる。既存の設定がある場合は上書きせず、permissions と sandbox のキーだけ統合してほしい。以下は公式ドキュメントを基に組んだ一例で、あらゆる経路の読み取りを防ぐ保証はない。導入後、自分の環境で実際にブロックされるかを必ず確かめること。

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "allowUnsandboxedCommands": false,
    "filesystem": {
      "denyRead": ["~/.ssh", "~/.aws", "~/**/.env"]
    }
  }
}

permissions.deny はReadツールやcatを止める柵、sandbox.filesystem.denyRead はBashから起動されたPythonやNodeも含めてOSが止める壁だ。allowUnsandboxedCommands: false は、サンドボックスで失敗したコマンドをサンドボックスの外で再実行する逃げ道を閉じる設定である（bypassモードではこの再実行が確認なしで走るため、特に重要だ）。その代わり、サンドボックス内で動かないコマンドは excludedCommands に登録しない限り実行できなくなるので、最初はエラーが増える覚悟がいる。

確認は簡単だ。Claudeに「.envを読んで」と頼んで拒否されればReadの柵は効いている。サンドボックス側は、Bashで python3 -c "print(open('.env').read())" を実行させて失敗するかを見る。

ただし、壁にも死角がある。サンドボックスのドキュメントによれば、サンドボックスが囲むのはBash・PowerShell・Monitorのコマンドだけで、Read/Editなどのファイルツール、MCPサーバー、フックはサンドボックスの外で動く。また動作環境はmacOS、Linux、WSL2で、ネイティブWindowsでは使えない。だからこそdenyルールを捨てずに残す。

フックで独自チェックをしている人（Claude Code Modsとフックの解説も参照）は、2.1.295で追加された onFailure: "block" も見ておきたい。フックが起動できない、タイムアウトした、想定外の終了コードを返した場合に、操作を通さずブロックする指定だ。2.1.288で「マッチ失敗時はブロック」になった流れと合わせ、失敗したら閉じる（fail closed：エラー時は許可ではなく拒否に倒す）方向へ寄せているのが今回の一連の修正の芯だと、PMとしては読んでいる。

正直に書くと、bubblewrapやSeatbelt（それぞれLinuxとmacOSの隔離機能）が内部でどう隔離しているのか、自分は技術的に説明しきれない。わかっているのは、「Claudeに書かせたコマンドの文字列を、Claude Codeが文字列で検査する」仕組みには構造的な限界があると考えられ、公式ドキュメントも「セキュリティ境界ではない」と書いている、という一点だ。未知のリポジトリを開く、bypassモードで放置する、といった使い方をするなら、コンテナやVMで丸ごと隔離するところまでやる。

上司・チームに共有するなら

関連記事

• Claude Codeのdenyルールが無効化される脆弱性｜50個のサブコマンドで安全装置が消える（2026年4月）
• Claude Code Auto Mode完全ガイド｜承認地獄から解放される新機能
• GitSpawn：AIコーディングエージェント7種を貫いたgit config RCE脆弱性
• Claude Code —restrictedモード解説：CI/CDリスクとAnthropicの回答
• Claude Code security-guidanceの正体｜3層レビュー
• IDEsaster：AI IDEの脆弱性まとめ

---

免責事項: 本記事は2026年10月11日時点の公開情報（Claude Code公式CHANGELOG、公式ドキュメント、GitHub Issue、各報道）に基づく。Claude Codeは頻繁に更新されるため、仕様や挙動は変わる場合がある。記載した設定は一例であり、特定の環境での安全性を保証するものではない。セキュリティ上の判断は各自の責任で行い、最新の情報は公式ドキュメントで確認してほしい。Claude、Claude CodeはAnthropic PBCの商標または登録商標である。本記事は同社と関係のない個人による解説であり、同社の公式見解ではない。記載した設定や手順の利用によって生じた損害について、筆者は責任を負わない。