審批與權限：兩個旋鈕，一個下拉框

下面是一個可以擰的權限控制檯。左邊兩個旋鈕各管一件事，右邊下拉框是預設。先選一個操作，點「播放」看這次工具呼叫一路闖關的過程；然後隨便擰旋鈕、換預設，再跑一遍，看同一個操作的命運怎麼變。

先給結論：DSH 把權限這個大詞拆成了兩個互不打聽的小問題。旋鈕一 sandbox/mode 回答的是這條命令的檔案效果允許到什麼程度，取值 read-only、workspace-write、danger-full-access 三檔，只管檔案系統，網路和行程可見性都不在它的詞彙表裡（docs/subsystems/sandbox.zh.md 開頭的定義）。旋鈕二 approval/policy 回答的是碰到需要人拍板的事問不問，取值 ask、never 兩檔。

兩個旋鈕在日誌裡也是兩種獨立事件：sandbox/mode 和 approval/policy。執行、提示詞、回放，全都只讀這兩種旋鈕事件的摺疊結果。這就是正交的實際含義：擰任何一個，另一個紋絲不動。

然後是那個下拉框。ctx.permissionPresets 維護一張表：名字對映到一個旋鈕組合。預設表就兩行，workspace-write 對應 workspace-write 加 ask，danger-full-access 對應 danger-full-access 加 never（permission-presets/src/index.ts 第 167 至 176 行的預設配置）。它是可選能力，不在 agent loop 主幹上，也不擁有任何強制執行。

切預設時發生什麼？三條事件，順序固定：先追加一條只記日誌的 permission/preset 記下你的意圖，再透過兩個旋鈕各自的規範 setter 寫 sandbox/mode 和 approval/policy，而且只寫生效值真的變了的那個。重新選中當前預設？什麼都不追加。回放時執行層只認旋鈕事件，preset 事件的唯一作用是當兩個預設共享同一組合時，記住你當初選的到底是哪一個名字。

還有 custom。它是保留字，表裡不許有叫這個名字的條目（外掛載入時就拋異常）。當你手動把旋鈕擰到一個表裡沒有的組合，current() 才派生出 custom 給客戶端顯示。它只出不進：可以是當前狀態，永遠成不了切換目標，也絕不出現在事件 payload 裡。所以演示裡的下拉框把它做成了灰色不可選項，這正是原始碼的行為。

有個邊界問題值得摳：如果一個外掛在審批服務掛載之後，用 prepend 往應答者鏈最前面塞一個全部放行的應答者，能不能繞過 never？答案是不能，因為 never 根本不在鏈裡執行。看 decide() 的開頭：

  private async decide(req: ApprovalRequest, session: Session): Promise<ApprovalOutcome> {
    const signal = req.signal
    if (signal?.aborted) return 'cancelled'
    // The 'never' policy is decided HERE, before any dispatch: a listener
    // registered with `prepend: true` after this service mounts would sit
    // ahead of any gate LISTENER, so a listener-shaped gate cannot keep the
    // documented promise that 'never' rejects deterministically regardless
    // of registration order — only the service's own request path can.
    if (this.effectivePolicy(session) === 'never') return 'rejected'

註釋把設計意圖講完了：never 的裁決點在服務自己的請求路徑上，任何監聽器形態的門都保不住與註冊順序無關這個承諾。往後看第 317 至 329 行，ask 路徑的兜底同樣密不透風：鏈的無應答預設值是 unavailable，拋異常的應答者被摺疊成 unavailable，返回怪值的也歸一化成 unavailable。

預設只是快捷方式，這句話的全部實現是一個十四行的私有方法 apply()。它做三件事，順序固定。第一步 resolve(name) 查表，名字不在表裡直接拋異常，異常訊息還會把已知的表鍵列出來。第二步對照 current() 的派生結果：你選的名字和當前生效的預設不同，才追加一條 permission/preset 事件記下意圖；重選當前預設，這一步什麼都不寫。第三步挨個檢查兩個旋鈕，預設宣告的沙箱模式與事件折疊出來的生效值（拿不到就用部署預設值兜底）不同，就調 setSandboxMode() 寫一條旋鈕事件；審批策略同理，走傳入的 setApproval 寫入。誰的生效值沒變就跳過誰。

所以切預設沒有第三個執行路徑，也沒有隱藏狀態：一條意圖日誌，加上至多兩次走各自規範 setter 的旋鈕寫入，日誌裡追加了什麼，執行層就摺疊出什麼。派生 custom 的邏輯在同檔案 derive()：先看上次選的預設還配不配當前旋鈕值，配就保住它；不配就按宣告順序找第一個匹配的表項；都不匹配才返回 custom。

出處：packages/interaction/permission-presets/src/index.ts 第 379 至 392 行（apply()）、第 309 至 321 行（derive()），核對日期 2026-08-13。

Claude Code 把同一塊地盤做成了單一的 permission mode 軸：default、plan、acceptEdits、bypassPermissions、dontAsk 五檔（還原原始碼 restored-src/src/utils/permissions/PermissionMode.ts 第 44 至 91 行，見書稿第 7 章），外加一張 allow / deny / ask 三種行為的規則表，規則內容可以細到 Bash(git commit:*) 這種命令前綴。

對照著看，摺疊的代價就顯出來了。dontAsk 大約等於 DSH 的 never，bypassPermissions 大約等於 danger-full-access 加 never，但這五檔在一根軸上滑動，沙箱收多緊和問不問人被綁在一起賣。DSH 的雙旋鈕能表達 read-only 加 ask 這種組合：沙箱只讀兜底，遇到確需寫入的操作彈窗問一次，一次放行。在 CC 的模式軸上找不到直接對應的檔位。反過來 CC 也有 DSH 雙旋鈕表達不了的東西：規則表是按工具和命令前綴的細粒度控制，DSH 的兩個旋鈕都是會話級別的全域值，工具粒度的門禁要靠 hook 層去做。兩邊各自把複雜度放在了不同的地方。Grok Build 的授權鏈走的又是另一條路（從工具請求到受限執行逐層放行），站內 Grok 完整授權鏈 一課有逐層拆解，可對照閱讀。Codex 則在同一道題上疊了兩層：命令級的 execpolicy 用精確前綴加反例把例外釘在載入期，Guardian 更進一步，用一次模型審查把彈窗從主路徑上拿掉。