結論：許可領域と秘密ファイルdenyを重ねる
Claude Code 2.1.236のmacOS sandboxでは、**/.envのようなwildcard read-denyがallowed read region内でも優先され、matching directoryの内容を含め、renameによる回避も防ぐよう修正されました。repository全体を作業対象にしながら、secret、credential、production設定だけをdenyする多層防御に使えます。ただしsecret manager、権限分離、漏えい時のrotationは別に必要です。
読者の具体的な困りごとは、Claude Codeへrepositoryを許可すると、sourceと同じtreeにある.envや秘密設定まで読める可能性を判断しにくいことです。この記事を読むと、deny pattern、適用scope、回帰test、HOLD条件を決め、安全な作業領域を設定できます。
次の行動：一つのtest repositoryで秘密ファイル候補を列挙し、.env、subdirectory、rename後の三ケースを読取拒否testへ追加してください。
公式仕様と対象範囲を確認する
公式Claude Code changelog 2.1.236はmacOS sandboxの修正として、wildcard read-deny ruleがallowed read region内で優先されること、matching directoryのcontentsも覆うこと、deny対象fileのrenameで回避できないことを明記しています。これはmacOSの変更です。Linux、WSL2、native Windowsへ同じ挙動を推測で広げず、各platformの公式sandbox文書と実機testを正本にします。
公式sandboxing文書では、sandboxがfilesystemとnetworkの境界をOS levelで実施し、macOSではbuilt-in Seatbeltを使うと説明しています。LinuxとWSL2はbubblewrapとsocatが必要で、native Windowsは非対応です。sandboxが利用できない場合に通常実行へ戻る既定動作もあるため、企業の必須gateではsandbox.failIfUnavailableを検討します。
公式settings文書の例には、Read(./.env)、Read(./.env.*)、Read(./secrets/**)のdeny ruleが示されています。Managed、User、Project、Localのscopeと優先順位も確認できます。秘密情報を守るruleは個人任せにせず、Managed scopeで配布し、project側が上書きできない構成を基本にします。
deny patternを四つの軸で比較する
- 正確なpath：
Read(./.env)は明確ですが、subdirectoryや別名を取りこぼします。小さなrepositoryの最小構成に向きます。 - 拡張pattern：
Read(./.env.*)は環境別fileを覆えますが、nested directoryを別に考える必要があります。 - wildcard：
Read(**/.env)やsecret directory patternは深いtreeを覆えます。広すぎるdenyで必要fileまで止めないようtestします。 - directory deny：
Read(./secrets/**)は配置規則と合わせやすく、秘密情報を専用directoryへ集約できる組織に向きます。
比較軸はcoverage、誤遮断、変更耐性、監査性です。patternを増やすだけでは、別名のcredential、certificate、SSH key、cloud設定を見落とします。まず秘密情報inventoryを作り、file名、directory、生成元、owner、rotation手順を整理します。その後、deny patternとsecret scannerを対応付けます。
denyは「読ませない」境界であり、repositoryへsecretをcommitしてよい理由にはなりません。可能ならsecret managerやruntime injectionへ移し、local fileはdummy値のexampleに置き換えます。やむを得ずlocal fileを置く場合はgitignore、filesystem permission、sandbox deny、log redactionを重ねます。
macOSで検証する7手順
- Claude Codeを2.1.236以降へ更新し、macOSのtest端末でversionを記録します。
/sandboxを開き、sandboxが有効でresolved settingsが想定scopeから来ているか確認します。- test repositoryへdummy値だけの
.env、nested.env、secrets/を用意します。 - settingsのdenyへ正確なpath、wildcard、secret directory patternを追加します。
- allowed read region内から通常fileが読め、秘密fileだけ拒否されることを確認します。
- deny対象fileを別名へrenameする操作をtestし、内容を読めないことを確認します。
- 結果、version、settings scope、失敗時の挙動を監査記録へ残し、Managed配布を判断します。
testには実際のcredentialを使いません。「DUMMY_SECRET_DO_NOT_USE」のような識別可能な偽値を置き、transcript、tool output、debug logへ現れないことを確認します。拒否message自体がpathや値を過剰に表示しないかも見ます。test後はdummy fileを削除するか、fixtureとして明確に隔離します。
設定を広げる前に、通常業務への影響を測ります。build toolが.envを必要とする場合、Claude Codeに読ませるのではなく、許可されたwrapperが必要最小限の値をprocessへ渡す設計を検討します。denyを解除して解決すると、多層防御が一番必要なproduction作業で例外が常態化します。
企業チェックリストとHOLD条件
- 2.1.236以降である
- macOS対象と確認した
- sandboxが有効である
- failIfUnavailableを判断した
- 秘密情報inventoryがある
- dummy値でtestする
- root .envを拒否できる
- nested .envを拒否できる
- directory内容を拒否できる
- rename回避を拒否できる
- 通常sourceは読める
- Managed scopeを検討した
- logへの露出を確認した
- rotation手順がある
- platform差を記録した
HOLD条件は、sandboxが起動していない、unsupported platform、denyの配布scopeが不明、実secretでしかtestできない、通常fileと秘密fileを分離できない、失敗時にunsandboxed実行へ進む可能性を制御できない場合です。拒否testが一つでも失敗した端末は、secretへ触れる業務に使いません。
incident時はdeny設定の修正だけで終了せず、値が読まれた可能性を評価し、credentialをrotationします。transcript、debug log、shell history、CI artifact、外部送信先を確認し、露出範囲を記録します。設定は将来の読取を防ぎますが、過去に露出したsecretを無効化する機能ではありません。
よくある質問と次の行動
permission denyだけで十分ですか？
重要な境界ですが単独では十分ではありません。secret manager、repositoryからの除外、OS権限、rotation、監査を併用します。
allowed read regionを狭める方が安全ですか？
基本は最小権限です。そのうえで作業領域内に混在する秘密fileをwildcard denyで遮断し、二層にします。
Linuxでも同じpatternを使えますか？
設定表現が似ていても、この修正はmacOS明記です。Linux sandboxの依存とresolved settingsを実機で確認してください。
修正内容は公式Claude Code changelog、隔離の仕組みは公式sandboxing、denyとscopeは公式settingsで公開直前に確認してください。
credential maskingは秘密情報を見せない設定ガイド、workspace trustは信頼判断ガイド、MCP診断のredactionはMCP秘密情報ガイドへつなげます。Miraigentの無料診断では、秘密情報inventory、sandbox scope、deny test、incident対応を整理します。