1. 痛點拆解：exec 變成「全拒絕」往往不是模型壞了，而是審批鏈與沙箱默認一起變了
（1）cron / 子代理靜默失敗：2026.4.x 一類版本把工具執行與沙箱的默認策略收緊後，舊配置裡常見的 security: "none" 或缺失欄位會落到拒絕路徑；UI 裡「一切正常」但任務隊列不再落盤命令輸出。（2）雙真源：exec-approvals.json vs openclaw.json 裡的 tools.exec：社區排錯裡反覆出現「只改了一處，另一處在啟動時被覆蓋」——你必須把它們當作同一門禁的兩扇窗而不是兩份無關配置。（3）Sandbox 容器註冊表殘留：升級後第一次 exec 會創建/復用容器名；若註冊表與 Docker 實際狀態漂移，會出現反覆 recreate 失敗或舊容器佔用 profile。（4）遠程 Mac Gateway：launchd 與交互 shell 的 OPENCLAW_* 不一致時，你在 SSH 裡跑的 openclaw logs 看到的拒絕原因，可能與 Gateway 進程加載的不是同一份 JSON。
2. 症狀—根因矩陣（先分層，再動刀）
| 現象 / 日誌關鍵詞 | 優先假設 | 第一動作 |
|---|---|---|
exec denied / allowlist miss / 工具調用秒拒 | tools.exec 檔位、審批鏈或沙箱默認組合觸發 deny | 只讀跑 openclaw doctor；對照 tools.exec.security / ask 與 exec-approvals.json 是否同源 |
| cron 任務「成功觸發」但沒有副作用 | 子進程在 sandbox 內被拒絕或輸出被丟棄 | 抓取同時間窗的 openclaw logs + Gateway unit 日誌；用最小命令 whoami / date 做探針 |
| Docker 報錯容器名衝突 / 無法 rm | sandbox 註冊表與真實容器不一致 | 按「備份後清理」順序處理容器與 ~/.openclaw/sandbox/containers.json（先讀官方/發行說明再刪） |
| CLI 與 Gateway 行為不一致 | 雙真源環境變量 / 多個 openclaw.json 搜索路徑 | 對照《Docker WS 與 Token》做 env 收斂 |
3. 落地五步走：把恢復寫成可審計 Runbook
- 快照：備份
~/.openclaw、workspace、當前openclaw.json、exec-approvals.json與 sandbox 目錄清單（tar或 git）。 - 凍結真源：列出 launchd / Docker / shell 中全部
OPENCLAW_*，標註誰最後寫入 Gateway 進程（openclaw gateway status+ 進程環境）。 - 對齊 tools.exec：在
openclaw.json內顯式設置tools.exec.security與tools.exec.ask（與團隊策略一致），避免依賴隱式默認。 - 對齊 exec-approvals.json：用最小 profile 驗證「單用戶自建」與「多 Agent」兩條路徑；變更必須進工單與回滾段落。
- 沙箱與日誌門禁：清理容器前做 dry-run；然後
openclaw channels probe→ 分層openclaw logs，禁止跳過 probe 直接改模型路由。
4. 可引用閾值與紅線（評審向）
- 若生產環境存在兩處及以上可改變
tools.exec有效檔位（JSON 片段 + 未文檔化 env + CI 注入），必須在上線前收斂為單一真源，否則按 P0 阻塞。 - 升級後 24 小時內必須完成一次「最小 exec 探針 + cron 一次觸發」雙演練，並保存各 3 行以上 logs 片段，否則視為未驗收。
- 遠程 Mac 上若 Gateway unit 與交互 shell 的
OPENCLAW_STATE_DIR（或等價路徑變量）不一致，優先修復 supervision，再排 exec——否則你會在錯誤目錄裡改 approvals。
5. 與升級總清單、Task Brain、Docker 文的交界
問：我已經按《升級 breaking / 鑑權 v2》跑過 doctor，為什麼 exec 仍全拒？因為 breaking 清單覆蓋目錄遷移與鑑權，而 4.x 的 exec 路徑還疊加了沙箱默認與審批枚舉校驗；本文矩陣優先處理 tools/exec/sandbox 三層。
問：Task Brain 後還要再看 exec 嗎？要。《Task Brain 安全落地》管控制面與技能策略，但真正落盤命令仍走 tools/exec；兩者日誌關鍵詞不同，應分開取證。
問：Docker 部署要不要重做？不一定。先按《Docker WS 與 Token》核對網絡與 token，再決定是否需要重建 sandbox 側車。
6. FAQ：回滾、團隊多機器與最小權限
問：能直接全局 ask: off 嗎？單用戶自建與生產多租戶不是同一風險模型；若必須臨時放寬，應寫在限時變更單裡並配自動回滾時間，而不是永久寫進倉庫。
問：清理 sandbox 會不會丟狀態？會可能影響容器緩存與本地工件；清理前備份 workspace 與註冊表 JSON，按「先停 Gateway → 再刪容器 → 再刪註冊表條目」降低競態。
問：官方 install 路徑還要再看嗎？建議對照《install.sh 與 security audit》覆核暴露面，避免 exec 放寬同時把監聽面放大。
7. 深度分析：為什麼「升級無痛」必須包含 exec 預檢
Agent 產品的連續性來自三件事：會話、記憶、可執行工具鏈。2026 年行業整體向默認更安全擺動，exec 與沙箱策略必然更頻繁地成為升級變更點；如果只驗頻道與模型路由而不驗 exec，團隊會在周一早晨收到「助手變笨了」的體感投訴——本質是工具靜默拒絕而非推理質量下降。
對遠程 Mac 常駐 Gateway 的用戶，exec 問題還會被系統更新與 Xcode CLT放大：shell 路徑、Python/Node 前綴、Docker context 任一漂移，都可能讓 sandbox 內的命令找不到二進位。把「最小 exec 探針」寫進 launchd 健康檢查，比事後讀一小時的 logs 便宜一個數量級。
最後一層是文化：把 exec 配置與 approvals 變更視作資料庫 schema 遷移一樣對待——需要評審、需要回滾腳本、需要雙人覆核。否則你會在 Slack 裡看到「誰改了一行配置讓整個 cron 停了」的經典事故；這類事故的隱性成本，通常遠高於租一臺專用遠程 Mac 做預發驗證。
8. 收束：本機排通後，生產仍建議隔離 Gateway
（1）當前方案的客觀限制：exec 與沙箱策略耦合多版本默認值；雙真源與容器殘留會讓排錯長尾化；筆記本與伺服器混用同一 home 目錄時路徑假設更脆。
（2）為什麼遠程 Mac Gateway 往往更穩：可把預發/對照與個人開發機隔離；固定拓撲與統一 launchd 單元更易做健康探針與回滾。
（3）與 MACGPU 場景的銜接：若你希望用低門檻遠程 Mac做「升級預演 + exec 探針」而不是在生產本機試刀，MACGPU 提供可租賃節點與幫助入口；下文 CTA 直達首頁套餐與幫助（無需登錄）。