Claude Code 2.1.289 的版本公告列出一項權限修正：在受管理機器上，複合 shell（命令列殼層）指令中巢狀部分的拒絕（deny，拒絕規則）或詢問（ask，要求確認規則），先前可能無法在核准使用者自行安裝的 mod（擴充模組）時持續生效。這項描述指向特定命令組合與管理情境，不能直接推成所有使用者、所有 shell 指令都受影響。團隊準備升級時，先釐清規則由哪裡提供，再於隔離環境確認實際行為。
一、Claude Code 2.1.289 修正的權限問題，範圍在哪裡？
公告提到的是受管理機器上，複合 shell 指令某個巢狀命令的 deny 或 ask 規則，在核准 user-installed mod（使用者自行安裝的擴充模組）期間未能持續生效。公告沒有宣稱一般個人環境或所有命令都遇到相同狀況。
複合 shell 指令是把多個命令接在一起執行，例如以 && 串接、用 | 傳遞輸出，或將另一個命令放進命令替換中。公告的修正描述聚焦在巢狀部分的拒絕或詢問規則，以及受管理機器上的使用者安裝 mod 核准流程。這幾個條件應合在一起理解，不能只看到「shell 權限」就假設每種權限模式都曾失效。
這三個條件分別代表不同的驗證邊界。受管理機器可能同時受組織政策與使用者設定影響，單看專案內的規則檔，無法知道最後是哪一層提供規則。複合命令又可能包含外層操作與巢狀操作，規則比對對象未必等於整串文字。mod 核准則是另一個授權流程；測試時應記錄核准狀態，避免把同時發生的核准事件誤判為規則本身的效果。把三者拆開記錄，才有辦法在異常時定位是哪個環節不同。
公告沒有交代問題的程式根因、發生條件的完整組合，也沒有列出受影響環境清單。因此，無法僅憑版本說明斷定問題來自規則解析器、政策載入順序或 mod 的核准介面。排查時可以把這些當作待驗證假設，分別檢查版本、實際載入的規則來源、命令解析結果與核准事件；在得到可重現的差異之前，不宜把其中一項寫成已確認根因。
「修正受管理機器上，複合 shell 指令巢狀部分的 deny 或 ask 規則，在 user-installed mod 核准時未能持續生效。」— Anthropic，Claude Code 2.1.289 版本公告（譯）
同一份公告也列出 Bash（Claude Code 的命令執行工具）規則在沙箱自動允許命令時，可能漏看環境變數前綴後命令，以及裸變數指定後命令的修正。這是公告中的另一項 Bash 規則問題，閱讀或測試時應與巢狀 deny、ask 規則分開記錄；官方公告沒有說明兩者由同一原因造成。
二、deny、ask 與命令核准流程各自代表什麼？
deny 規則阻止符合條件的工具操作，ask 規則要求確認，allow 規則則讓符合條件的操作不必逐次詢問。規則是否符合，仍要看命令拆分方式、比對內容與實際生效的設定來源。
Claude Code 官方權限文件把兩種判定分開說明：複合命令中的每個子命令都必須各自符合規則，allow 才能涵蓋整組命令；deny 或 ask 規則則在任何一個子命令符合時適用。官方文件也將巢狀子 shell、命令替換與控制流程中的命令納入規則判定範圍。前者關乎複合命令中每一段能否獲准，後者關乎是否有任何一段觸發拒絕或詢問，不能把兩條判定合併成「拆開後一律相同處理」。
例如，printf 'ok' && printf 'done' 包含兩個子命令；若團隊測試的是 allow 規則，必須確認兩段各自匹配才可預期整組通過。若第二段換成一個符合 deny 規則的巢狀命令，檢查重點則是該命令是否仍被攔下。這樣設計測試案例，是為了確認命令邊界與規則比對結果，不是要推測公告中未公開的內部實作。
「每個子命令都必須各自符合規則。」— Anthropic，Claude Code 權限文件「Compound commands」（譯）
官方文件也說明，命令規則依 Claude Code 看見的命令文字比對；同一程式若改用不同路徑或包在另一層 shell 中，原規則可能不再符合。因此，測試要保留完整命令。deny 與 ask 也不等同作業系統層級的隔離或網路管制；若要求限制檔案或網路存取，還需確認部署環境另有何種執行層控制。
規則的優先順序同樣會影響解讀。文件列出的順序是 deny、ask、allow，先命中的類型決定處理方式；較具體的 allow 不會自動排除已命中的 deny。這表示「我看到一條 allow」不能單獨解釋命令為何獲准，也不能據此反推所有其他規則無效。實際檢查時應一併記下相符規則與來源，特別是團隊逐步累積設定、不同層級各自維護規則的情況。
公告表示 2.1.289 修正了特定管理環境中的規則持續生效問題，但沒有公開足以重建問題的完整設定組合或技術根因。文件描述的是目前規則應如何判斷，版本公告描述的則是該版本列出的修正；兩者可協助設計驗證案例，卻不足以證明每一套部署都已通過驗收。
權限設定和執行結果也要分開看。規則檔裡有一條 deny，不代表測試中的命令一定符合它；看到一次命令被擋，也不能證明所有相似寫法都會被擋。官方文件指出規則會依 deny、ask、allow 的順序判定，且 /permissions 可檢視規則及其設定來源。遇到重疊規則時，先確認優先順序與來源，再解讀測試結果。
升級公告描述修正行為，不等於 Claude Code 已刪除既有權限設定、改變設定格式，或替組織完成所有權限驗收。版本公告也未涵蓋每種作業系統、shell、規則組合與管理部署；這些環境是否符合團隊政策，要以實際設定和測試結果確認。
三、升級前後怎麼檢查既有權限設定？
先記下目前版本、設定檔位置與管理政策，再以隔離環境中的無副作用命令，分別檢查 allow、ask、deny 是否呈現預期結果。使用 user-installed mod 的團隊，也要獨立確認其核准流程。
- 記錄目前狀態。 用
claude -v記下 Claude Code 版本，並記錄適用的組織管理設定，以及個人、專案或本機設定檔的位置。可在 Claude Code 中查看/permissions，核對規則清單和顯示的來源；不要只憑某一份專案設定檔推斷組織政策。 - 準備隔離測試環境。 使用可丟棄的測試專案或虛擬環境，不連接正式資料、憑證或生產服務。挑選只輸出固定文字的命令來測試規則，避免用刪除、覆寫、網路傳輸或會改動資料的操作驗證權限。
- 分開測試三種規則。 為 allow、ask、deny 各準備一個只輸出文字、且彼此不重疊的測試命令，確認命令是否執行、是否出現確認提示、是否遭阻止。若團隊規則有重疊，再另外驗證優先順序，並保留測試時的規則來源與結果。
- 檢查巢狀與複合寫法。 在測試命令中加入安全的子命令組合，逐一觀察被規則涵蓋的部分。測試目的在確認規則符合情況，不需模仿具破壞性的真實命令。
- 驗證 mod 核准流程。 若團隊使用 user-installed mod，確認核准是在預期的組織政策下進行，並確認規則測試不會被 mod 核准流程改變。記錄結果後，再決定是否將新版本納入正式工作流程。
這些步驟是部署前的檢查建議，不是 Anthropic 公告所描述的官方測試程序。若某個規則沒有呈現預期結果，先比對生效來源、命令寫法和核准紀錄，再依團隊變更流程處理；不要只因版本號較新，就視為驗收完成。
測試紀錄至少應包含版本與執行介面、作業系統及 shell、權限模式、規則來源、完整命令、預期結果、實際結果，以及是否經過 mod 核准。每次只改一個條件，例如先固定設定與命令比較升級前後，再固定版本測試巢狀形式，最後才加入 mod 核准流程。若同時更換版本、規則檔與執行環境，即使結果不同也難以指出差異由何而來。
測試表可把同一條巢狀命令固定下來，再分別記錄升級前後的預期與實際結果。例如，外層只輸出固定文字，內層放入一個符合測試 deny 規則的安全命令；若結果不同，記下該規則來自哪個設定層、是否出現 ask 提示，以及測試當下是否完成 mod 核准。接著維持版本和命令不變，只改變核准狀態重做一次，才能看出差異是否與核准流程同時發生。這是隔離變因的排查方法，不能據此宣稱核准流程就是公告問題的原因。將終端輸出連同測試時間、版本一併保存，管理者較容易重現同一案例。
權限來源可以從 /permissions 顯示的規則和設定檔路徑開始查，再依管理者提供的部署方式核對組織政策、使用者設定、專案設定與本機設定。若畫面中看得到規則，但命令行為與預期不同，可先確認測試工作階段使用的版本與權限模式，再核對規則是否從預期路徑載入。
接著確認命令分成哪些子命令、巢狀部分長什麼樣，最後檢查 ask 提示或 mod 核准是否介入。逐層排查能避免把「規則檔寫了什麼」誤當成「執行時實際套用了什麼」。
個人環境與組織環境也不宜混用驗收結論。個人專案可以先用自身設定確認單一工作流程；受管理環境還需由管理者提供政策來源與核准方式，並在相同政策下重做案例。若個人測試通過，最多只能說該設定與該命令組合的結果符合預期，不能代表組織機器上的管理政策、不同 shell 或其他 mod 都有相同結果。將測試環境和適用範圍寫進紀錄，能讓之後接手的人知道結論可用在哪裡。
若測試失敗，先保留原始設定與命令，再用最小案例重現。逐一拿掉外層命令、巢狀命令或核准步驟，觀察哪個條件改變後結果不同；若只有特定包裝方式或變數前綴造成差異，就把該形式獨立成案例。這些是排查線索；未經文件或可重現證據確認，應稱為觸發條件，不宜直接定為根因。
四、什麼情況該升級，什麼情況要先驗證流程？
使用受管理機器、複合 shell 命令的巢狀 deny 或 ask 規則，或採用 user-installed mod 核准流程的團隊，應把這項修正列入升級驗證。是否立即導入，仍取決於團隊的維護節奏和測試結果。
如果既有工作流程依賴 Bash 規則攔截命令，公告另提及的環境變數前綴與裸變數指定情境也值得列入測試，但應獨立設計案例，避免把不同修正混成單一結論。一般使用者可先查明自己是否使用相關規則與受管理設定，再按自身更新流程決定時程。更新不會代替管理者確認權限來源、mod 審核責任或命令實際比對結果。
- 2.1.289 公告描述的是受管理機器上，複合 shell 指令巢狀 deny 或 ask 規則與 user-installed mod 核准相關的特定修正。
- 升級前記錄版本與規則來源，升級後用隔離環境及無副作用命令逐項驗證。
- Bash 環境變數前綴等相鄰修正另行測試，不能由單一公告推定所有權限風險都已消失。
常見問題
Q1：Claude Code 2.1.289 會改寫既有權限設定嗎？
版本公告列出一項權限行為修正，沒有說明會刪除既有規則或變更設定格式。升級前後仍應檢查實際設定來源與命令結果。
Q2：怎麼確認 Claude Code 目前使用哪些權限規則？
在 Claude Code 執行 /permissions，查看規則清單與每條規則的來源。組織管理設定、個人設定與專案設定可能各有作用，應依畫面和部署政策核對。
Q3：升級後測試權限，可以直接用會刪檔的命令嗎？
不建議。使用隔離環境裡只輸出文字的測試命令即可觀察規則結果，避免拿刪除、覆寫或外傳資料的操作測試權限。
Q4：一般個人使用者是否一定要立即升級？
公告針對受管理機器上的特定規則與 mod 核准情境。個人使用者可先確認是否使用相關設定，再依自己的更新安排決定；公告沒有要求所有使用者立即升級。
