Claude Code の deny に ../ を書いても止まらなかった報告：パス記法と実行経路の注意点
ミオ｜AI大好きな後輩
Claude Code の deny で作業フォルダの外を守ろうとして、../ で始まるパスを書いても書き込みが止まらなかった、という実測が Zenn に出ました。公式の permissions の docs にあるパスの書き方は4種類で、../ で始める形はその中にありません。
deny や allow で作業フォルダの外を守っている人と、Codex・Antigravity・Gemini CLI で同種の設定を書く人に関わる話です。筆者は AI の開発ツールの権限設定を公式資料と照らして追っていて、本稿は公式の docs、GitHub の issue、Zenn の記事を10月12日の朝（日本時間）に取得して突き合わせ、公式に書かれたことと報告を分けて整理しました。止め方の設計には踏み込みません。
公式 docs が書くパスの書き方
Claude Code の permissions の docsによると、Read と Edit の規則は gitignore の記法で、パスの書き方は次の4種類です。
- //path：ファイルシステムの根からの絶対パス
- ~/path：ホームディレクトリから
- /path：設定ファイルの置き場所が基準（プロジェクトの設定なら作業ディレクトリ）
- path または ./path：今のディレクトリから
先頭が1つのスラッシュの /path は、根ではなく設定ファイルの置き場所が基準だと、docs は注意しています。書き込みを止める規則は Edit(path) で、Write(path) は受け付けても参照されず、起動時に警告が出ます。
Zenn の実測と #89470
Zenn の記事は、Windows 10・Claude Code 2.1.296・非対話の claude -p（モデルは haiku）で、作業フォルダの外を ../ で指した Edit の deny を試しています。結果は、../ の規則は試した書き込みのどれも止めず、起動時の警告も出なかったというものです。Bash を自動許可しない場合の echo は拒否されましたが、deny なしでも拒否されており、この規則が止めた結果ではありません。同じ場所を //c/ から始まる絶対パスで書くと、Write ツール・Edit ツール・Bash の echo による書き込みは止まりました。
#89470 は別の件で、報告の本体は、--add-dir や additionalDirectories で足したディレクトリに、相対の glob の deny が効かないというものです。bug のラベルが付き、取得した時点で open です。9月28日のコメントで、別の利用者が additionalDirectories に ../sibling-repo-a を指定し、同じ ../ の形で Read と Edit の deny を書いたところ、読み取りも書き込みも通ったと報告し、../ は docs の4種類にないとも断っています。
パスが合っていても止まらない経路
docs は、Read と Edit の deny が及ぶ範囲を次のように書いています。
Claude Code の permissions の docs に基づき、パスの書き方が合っている Read・Edit の deny が及ぶ経路を並べた図です。図にない読み取り経路の例は本文で補足しています。sandboxing の docs によると、下段は対象パスを禁止し、Bash 経由のスクリプトと子プロセスをサンドボックス内で実行する場合の OS 制限です。除外コマンドやサンドボックス外の再試行には適用されず、許可範囲内の書き込みまで一律に止めるものではありません。サンドボックスは既定でオフで、macOS・Linux・WSL2 に対応します。ネイティブの Windows では使えません。
- Read・Edit などの組み込みのツール：deny が及びます
- Bash の cat・sed・tee とリダイレクト：docs が Bash で認識するファイルコマンドと出力先にも、deny が及びます
- スクリプトが自分で開くファイル：Python や Node のスクリプトが自分でファイルを開く場合には、deny が及びません
docs は、ファイル名を書かずに読むコマンド（作業ディレクトリでの grep -r pattern . など）にも及ばないと書いています。本稿の主題は書き込みで、これは読み取りの例です。
Zenn の記事も、Bash を自動許可した状態では、絶対パスの規則で守った場所に node のスクリプトが書き込めたと報告しています。docs は、OS の段で止めるにはサンドボックスを使うよう案内していて、Claude Code の sandboxing の docsによると、サンドボックスは既定でオフで、macOS・Linux・WSL2 で動きます。ネイティブの Windows ではコマンドがサンドボックスなしで動き、Windows で使うには WSL2 の中で Claude Code を動かします。
他社のツールの例
- Codex：Codex の permissions の docsは、ワークスペースの根の下に入れ子で書く subpath について、../other-repo のような親への移動は拒否されると書いています
- Antigravity：Antigravity の issue #798で、パスごとの deny が効かないと報告された件に、保守担当は、ファイルの権限は glob ではなくディレクトリの前方一致だと回答しました。報告者は試し直し、元の指摘のうち書き方・優先順位・サンドボックスの件は設定の誤りだったと認めています
- Gemini CLI：Gemini CLI の issue #20355は、CLI 0.30.0 で、policy の deny に commandPrefix として git branch -d（末尾に空白あり）を指定したのに、git branch -d test が実行されたという報告です。修正や原因の説明のないまま、活動がないことを理由に bot が2026年8月9日に閉じました
まだ分からないこと
- ../ で始める deny が仕様なのか不具合なのかは、Zenn の記事も分からないとしています。docs は ../ を名指しせず、規則はアンカーの下のファイルにしか一致しないと書くだけで、#89470 にも Anthropic 側の返答は取得した範囲でありません
- Zenn の結果は Windows 10・2.1.296・claude -p・haiku での実測で、対話モードや macOS・Linux、ほかのバージョンは記事が試した範囲に入っていません
次にやること
自分の deny に ../ で始まる規則があれば、docs が示す // の絶対パスか ~/ のホームからのパスに直せないかを見てください。ただし // の絶対パスはひとりの環境の置き場所に固定されるので、チームで共有する設定には移植できないと、#89470 のコメントは指摘しています。docs は、ユーザー設定の規則をすべてのプロジェクトに効かせるには、// か ~/ の形を使うよう案内しています。書いた規則が実際に止まるかは、Zenn の記事が、ダミーのファイルだけを使う手順とあわせて、試すことを勧めています。
止め方の設計は、既刊の Claude Code で止めたい操作を本当に止める で、deny・フック・サンドボックスを操作ごとに選ぶ形で扱っています。
参考になったら、記事下部のライクとXの共有ボタンから応援してもらえるとうれしいです。
この記事の販売者
