この症状を追うときは、まず「どの形の拒否ルールが効いていないのか」と「どの実行形態で起きているのか」を分けて見るのが近道です。今回の issue では、少なくとも次の 2 系統が報告されています。
ひとつは #87014 です。こちらは Claude Code 2.1.233、Linux、headless の claude -p 使用時に、permissions.deny の Read ルールが現在のプロジェクトの auto-memory ディレクトリ ~/.claude/projects/<cwd-slug>/memory/* を止められない、という報告でした。報告本文では、"deny": ["Read(~/.claude/**)"] のような glob deny を入れても、プロジェクトの memory ディレクトリ配下が読めてしまうとされています。
もうひとつは #98443 です。こちらは desktop app の Code tab で、.claude/settings.json と .claude/settings.local.json の両方に permissions.deny があるのに、Write や Edit などの拒否が効かないという報告です。本文の途中までしか見えていませんが、少なくとも「デスクトップアプリ側で、ローカル設定の deny が期待どおり強制されていない」という筋の問題として読めます。
ただし、筆者の環境で実際に取れた出力はこの切り分けに別の見方を足します。設定ファイルの有無を見た結果は次のとおりで、少なくとも今回の検証環境では、対象パスに設定ファイル自体が存在しませんでした。
[settings_structure]
~/.claude/settings.json: (存在しない)
/mnt/vda5/git/papoo/newsbot_openai/.claude/settings.json: (存在しない)
/mnt/vda5/git/papoo/newsbot_openai/.claude/settings.local.json: (存在しない)
つまり、今回の手元検証だけから言えるのは、「この環境では設定ファイルの実体を確認できなかった」というところまでです。permissions.deny の効き方そのものをこの出力から断定はできません。
一方で、環境情報は取れています。
[env_summary]
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-10-07T08:54:00+09:00
この情報と issue の内容を合わせると、少なくとも次のように切り分けるのが妥当です。headless の claude -p で permissions.deny が効かないのか、それとも desktop app の Code tab で local 設定が反映されないのかで、別の問題として見たほうがよさそうです。#87014 は前者、#98443 は後者の疑いがあります。
現時点で、ここから先の「こう直せば必ず回避できる」という手順は断定できません。少なくとも issue の記載だけを見る限り、#87014 は報告時点で再現手順つき、#98443 は open のままで、どちらも解決策が確立したとは言えません。読者側では、まず自分の再現形態が headless CLI なのか desktop app なのかを合わせ、そのうえで permissions.deny に入れたパスと、実際に触れてしまうファイルの位置関係を確認するのが出発点になります。
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-10-07T08:54:00+09:00