Claude Codeの../denyが無効

このテストは実用的な状況から生まれた。筆者はClaude Codeを2つの作業フォルダで使用しており、一方が他方を変更しないようにしたいと考え、company/.claude/settings.jsonにEdit(../shared/partner/**)と記述し、保護されていると想定していた。別の作業を試みている際にファイルが変更されていることに気づき、規則が機能していないことを初めて認識した。公式のConfigure permissionsドキュメントには//path、~/path、/path、pathまたは./pathがサポート形式として記載されており、../形式は含まれていない。筆者の実行では警告なしに失敗した。代わりにWrite(...)規則として記述すると、Write(path)はファイル権限チェックに使用されずEdit(path)を使うべき旨の起動警告が表示された。筆者の複数回の実行では、絶対パス規則はWriteツール、Editツール、Bashのecho >をブロックしたが、自動許可されたBash経由で実行されたnodeスクリプトはブロックしなかった。別の確認では、Read(./.env)で.envを拒否するとReadツールとcat .envは阻止されたが、自動許可Bash下ではnode -eスクリプトが依然として読み取れた。筆者はClaude Codeのドキュメントに、ReadとEditのdeny規則はPythonやNodeスクリプトが開くファイルをカバーせず、OSレベルで強制するにはサンドボックスが方法であると既に記載されていると指摘している。別のWindowsユーザーでファイル権限なしにClaude Codeを実行するか、仮想マシンやコンテナ内で実行し、本番キーを同じマシンに置かないことを提案している。