你設的唯讀資料夾，只要路徑裡有括號就等於沒設

你設成唯讀的那個資料夾，只要路徑裡有括號，過去一直是可寫的。

Claude Code 官方 changelog 的 2.1.260 版（標示 9 月 3 日）修掉這一條：路徑含括號的 Edit／Write／Read 權限規則，會被當成無效丟掉，或被 Bash 沙箱忽略。官方對後果只寫了一句話——這讓原本設成唯讀的資料夾是可寫的。像 Edit(/Users/you/work/(archive)/**) 這種規則，過去等於不存在。

同一版還有第二格。一條寫壞的檔案權限規則，例如少關一個 [，過去會讓每一次檔案編輯都失敗，錯誤是 Invalid regular expression。現在這種 deny 規則改成只守它字面上寫的那個路徑。一條寫壞，過去是全部停擺，現在是那一條退化成字面比對——兩種都不是你設定它的時候想像的行為。

第三格是 zsh。Bash 權限檢查過去會自動核准把命令替換藏在 REPORTTIME、REPORTMEMORY 或 DIRSTACKSIZE 賦值裡的指令，現在會停下來問你。這三個是 zsh 的內建設定值，沒有人會在日常指令裡寫它們——它們出現在這條修正裡，是因為那是一道縫。

第四格最值得單獨看，因為它是修好又退回。2.1.259（9 月 2 日）補上了 Read() deny 規則對 Bash 參數的覆蓋：--ignore-revs-file=.env 這類選項值、git diff 的檔案運算元、cd 目錄 && cat 檔案 這種複合指令，過去都繞得過去。隔一版，2.1.260 把這個修正整個退回，理由寫在 changelog 上：它會讓 Read(./**/build/**) 規則在所有模式下把 npm run build 一起擋掉，也讓 cd … && grep 在自動模式裡照樣跳提示。

所以今天的答案是：你那條 Read() deny 規則，管不到用這幾種寫法從 Bash 讀出去的檔案。 這不是還沒修，是官方權衡之後退回的狀態。把 deny 規則當密鑰保險箱用的人，這一格要自己補。

再往後一版，2.1.261（9 月 4 日）補了兩件同方向的事：危險的 rm 安全提示現在也攔得住寫成位置參數、以及包在雙引號 sh -c 腳本裡的 rm -rf；自動模式現在把「把內容打包進公開圖表渲染器網址」的連結視為一次上傳到該站，除非你自己開口要，否則不再自動放行。

把四格擺在一起，我的讀法是一句話：權限規則是字串比對，不是保證。 我們寫過代理人的三層授權、也寫過放手前先設好哪些能自動，但那些都在假設規則會照你寫的方式生效。這幾版證明中間還有一層：規則得先被正確解析，才輪得到它擋不擋得住。

而這一層過去不會講話。括號那條是靜默丟掉，寫壞那條是全部編輯失敗、錯誤訊息只丟給你一句正則表示式的抱怨，Read() 那條是補上又退回，兩次都不會有人通知你。2.1.260 起，Bash(ls) x 這種「右括號後面還帶字」的規則至少會被回報成無效設定，不再被靜默忽略——這是第一次有東西願意主動說「你這條沒用」。

升上 2.1.261 是最低限度，claude --version 兩秒的事。真正該回頭問的是另一題：你 settings.json 裡那幾條規則，你上次確認它們真的生效過是什麼時候？自動模式改成模型自己按核可之後，那幾行字就是唯一那道閘。我自己回頭看，答案是從來沒有——我只確認過我寫了它們。

查核備註：本篇是官方 changelog 的文件檢視，版本與日期照官方頁面標示。我沒有真的建一個帶括號的資料夾去撞那個 bug；退回之後 Read() deny 規則現在究竟覆蓋到哪裡，是我從 2.1.259 補上、2.1.260 退回這兩條記載推出來的，不是我實測的結果。