2026年 OpenClaw Exec Approvals（執行核准）在獨佔遠端 Mac（SSH 無頭）怎麼落地？tools.exec 策略、核准狀態檔與無 UI 保守回退的可復現決策矩陣 + FAQ
把「本機／遠端 shell 執行」從模型的一廂情願，收斂成可稽核、可過期、可在無圖形介面下維運的策略閉環：tools.exec 只是最後一棒，前面是核准與狀態檔。
1. 獨佔遠端 Mac + SSH 無頭：你要解決的真正問題
Exec Approvals 的目標不是「多彈一個視窗」，而是讓 Gateway 在執行前拿到可驗證的外部決策。在獨佔節點上，常見坑是：同一使用者下同時跑 CI、Gateway 與手動 ssh，核准狀態檔被併發寫壞；或 launchd 與互動式 shell 的 HOME、工作目錄不一致，導致「以為已核准、其實讀到另一份狀態」。
建議把環境拆成三條不變量寫進 Runbook：誰的使用者身分跑 Gateway、狀態檔只放在該使用者可寫目錄、核准權杖與工單 ID 一一對應且帶 TTL。若你仍在對齊節點配對與 CLI 能力位，可先對照 節點配對、node 子命令與核准流對照表 ，避免把 PATH／版本漂移誤判成核准失效。
2. tools.exec 策略：預設拒絕 + 分級放行
把策略想成四層，越往下越「不可逆」，越需要顯式核准或更短 TTL：
- L0 唯讀探測：
pwd、git status等——可走自動 allowlist，但仍建議記錄 trace。 - L1 建置與套件管理：
npm ci、xcodebuild——綁定固定工作副本與鎖定檔，限制併發與逾時。 - L2 寫系統與憑證：鑰匙圈、
sudo、修改 launchd——預設拒絕，除非工單 + 雙人覆核流程已定義。 - L3 出站與資料外洩面：
curl上傳、任意 URL——與出站代理／白名單聯動，執行前必須 Exec Approval。
與 Plugin Hooks 的「準入層」搭配時，可讓 Hooks 做參數摘要與雜湊，Exec Approvals 只管是否允許進入 exec 驅動；如此稽核欄位不會散落在多個外掛裡。需要端到端 Tool 稽核範例時可延伸閱讀 Plugin Hooks 與 Tool Call 稽核教程。
3. 核准狀態檔：路徑、原子寫、TTL 與觀測
無 UI 時，「狀態檔」就是人機協作的地面真相。建議形態（欄位名隨你使用的 OpenClaw 版本調整，語意保持一致即可）：
- 路徑：放在 Gateway 執行使用者下的固定目錄，例如
~/.openclaw/approvals/，禁止軟連結到共用卷除非明確需要跨工作階段共用。 - 原子寫：先寫
.tmp再rename，避免讀到半截 JSON；拒絕多程序同時改同一 ticket 檔卻不做檔案鎖的版本。 - TTL：
expires_at必須早於工單 SLA；過期後執行體應 fail-closed 並打明確指標approval_expired。 - 綁定維度：至少綁定
gateway_id+session_id+tool_invocation_id（或等價 trace），防止「一張批條被挪用到另一條工作階段」。
在 SSH 無頭上，用 ls -l、stat 與閘道日誌中的同一 invocation id 做三聯驗證，應寫進值班手冊的第一頁。
4. 無 UI 的保守回退：寧可停跑，也不要靜默越權
當核准通道不可用（IM 機器人掉線、工單系統 503、權杖輪換失敗）時，回退策略只有兩類是生產可接受的：
- Fail-closed：
tools.exec對 L2／L3 一律拒絕，模型收到結構化錯誤，任務進入「待人工」佇列。 - 降級到唯讀工具包：預先宣告的 L0／L1 白名單仍可執行，其他工具回傳同一錯誤碼，避免模型用側信道繞過。
不建議：把核准寫進「永遠 true」的環境變數方便偵錯卻忘了刪；或在無頭機上暫時 chmod 777 狀態目錄——這會把獨佔節點的安全邊界一次撕掉。第一次上機可參考
10 分鐘在遠端 Mac mini 上部署 OpenClaw：SSH 快速上手指南
先把目錄權限與啟動身分釘死，再掛核准。
5. 可復現決策矩陣（節選）
| 情境 | 是否有有效核准檔 | tools.exec 決策 | 使用者可見行為／指標 |
|---|---|---|---|
| L0 唯讀指令 | 不需要 | Allow（allowlist 命中） | 稽核 INFO；無核准檔 |
| L2 寫鑰匙圈／sudo | 需要且未過期 | Allow + 單次消費權杖（若支援） | 稽核 WARN；exec_high_risk 計數 +1 |
| L2／L3 任意 | 缺失／解析失敗 | Deny | 錯誤碼 APPROVAL_REQUIRED；不進執行體 |
| 核准服務不可用 | 無法簽發新權杖 | Deny（L2+）；L0／L1 可保留 | approval_backend_down；觸發值班頁 |
| 狀態檔被竄改（簽章校驗失敗） | — | Deny + 吊銷本工作階段後續 exec | approval_integrity_fail；資安工單 |
矩陣應納入版本控制：每次 OpenClaw 小版本升級後重跑一遍「矩陣列」的自動化契約測試，防止預設值從 opt-in 變為 opt-out。
6. SSH 無頭上的最小驗收腳本（思路）
- 用非互動 SSH 觸發一次應拒絕的 L3 呼叫，斷言日誌與回傳體都含
APPROVAL_REQUIRED。 - 模擬簽發最小核准 JSON（含 TTL），再觸發同一呼叫，斷言僅一次成功（若實作單次消費）。
- 把系統時間撥快過 TTL（或在測試環境縮短 TTL），斷言過期後 fail-closed。
- 併發兩路工作階段爭用同一 ticket id，斷言一路失敗且檔不被撕毀。
7. FAQ
Q：沒有桌面，核准是不是只能手改檔案？
A：生產上更推薦「工單系統／ChatOps／簽名 URL」產生權杖，由受控腳本原子寫入狀態檔；純手動適合 break-glass，並要雙人覆核與更短 TTL。
Q：模型能否自己寫核准檔繞過？
A：若模型能寫該目錄，你就已經輸了。狀態目錄必須對模型程序不可寫，僅閘道或獨立 sidecar 可寫；模型只能攜帶「權杖字串」，由閘道校驗後再落盤。
Q：和 node 子命令核准是不是一回事？
A：不同層面。node 配對／能力位管「誰能連上哪台閘道」；Exec Approvals 管「連上之後能不能動 shell」。兩者要在 Runbook 裡分章節寫清。
Q：核准太慢導致任務總失敗？
A：把長任務改成佇列作業（先落盤計畫，再非同步執行），並對模型側明確回傳「等待核准」狀態，避免無限重試打爆閘道。
在 Mac mini 上固化核准鏈更省事
Exec Approvals 與 tools.exec 依賴長期穩定的程序身分、磁碟與 launchd：獨佔遠端 Mac 上若頻繁換機或混用互動／守護環境，核准狀態檔最容易出現「讀錯目錄」類事故。Apple Silicon Mac mini 在同價位下通常具備更好的能源效率與統一記憶體頻寬，適合同時跑 Gateway、輕量稽核落盤與權杖校驗 sidecar，而待機功耗可維持在很低水準，適合小團隊 7×24 常駐。
從安全與總體擁有成本看，macOS 的 Gatekeeper、SIP 與 FileVault 讓無人值守節點的基線更清晰；靜音與低故障率也能減少 SSH 排障時間。若你希望把本文的決策矩陣與無頭回退策略落在最省心、最省電的硬體上，Mac mini M4 是目前非常值得考慮的起點——現在即可入手，讓執行核准真正可稽核、可復現。