雲端 Mac mini 上的 OpenClaw：macOS TCC、輔助使用、螢幕錄製與自動化權限（2026）
在租用的 Mac mini M4（香港、日本、韓國、新加坡或美國機房）上跑 OpenClaw 這類代理時，最常見的失敗方式其實很乏味：守護行程能啟動、日誌看起來也正常，但視窗焦點拿不到、像素讀不到、按鍵送不進去。十有八九根因在 透明度、同意與控制（TCC）——在系統設定裡由人工點「允許」之前，macOS 不會把輔助使用或螢幕錄製真正接進你的自動化目標。這份 2026 指南給出五列表格式的權限矩陣、七步且不可打亂的授權順序，以及日誌路徑的硬數字，讓你一次把環境配好，然後安心依賴 LaunchAgent 排程 與 鑰匙圈優先的金鑰衛生，而不必再守著筆記本反覆點彈窗。上述邊界穩定後，再透過 MCP 工具伺服器接入指南 擴充工具面——每個 MCP 行程仍繼承同一套權限與金鑰策略。把 TCC 當成發布清單的一項：與程式碼審查、金鑰輪替同級對待，才能在生產裡穩定重現「能點、能截、能鍵入」的行為。
為何雲端 Mac 上的 TCC 比辦公桌更「吵」
個人電腦上你多半是無意識地點完所有彈窗；在 ProxyMac 上團隊往往先 SSH 登入，而純終端機工作階段永遠不會把模態框推到眼前。更糟的是，有人把 OpenClaw.app 丟進 ~/Downloads 或 Dropbox 同步目錄——路徑一變，系統就視為另一套套件實例，舊授權會被悄悄作廢。正確流程是工程化的：先安裝到 /Applications，再安排一次真正的圖形工作階段，最後才談自動化。雲端維運還要考慮時區與值班：誰能在業務視窗內完成那一次圖形授權，應寫進值班表而不是臨時在群組裡喊人。
- 套件路徑穩定：在 plist 引用二進位檔之前，先把應用程式拖入
/Applications並完成一次版本對齊。 - 使用者一致：點「允許」的 UID 必須與執行
launchd作業的 UID 相同——不要「管理員安裝、一般員工跑」。 - 遠端現實：螢幕錄製類提示理論上出現在實體主控台；透過 VNC 多數仍可操作，但高延遲容易讓你錯過右上角小條——務必讀下文 VNC 小節。
權限矩陣（每一道門關掉時會發生什麼）
在指責模型延遲或 API 配額之前，先把這張表掃一遍，能省下大量無效排查時間。
| 權限門 | 受影響的 OpenClaw 能力 | 使用者可見現象 | 首選處理 | 備註 |
|---|---|---|---|---|
| 輔助使用 | 點選選單、向原生 Cocoa 控制項輸入文字 | 日誌出現「AXUIElementCreateApplication failed」一類錯誤 | 升級後在列表裡對該應用程式關再開一次 | 也會卡住不少 AppleScript 橋接場景 |
| 螢幕錄製 | 以像素為基礎的工具、瀏覽器畫布截取 | 黑畫面影格或點陣圖句柄為空 | 重新開啟隱私權面板；macOS 15 小版本後偶需重新授權 | 無法在無圖形工作階段中授予 |
| 自動化（Apple 事件） | 在受支援場景下指令碼化 Safari/Chrome | 提示「無權向該應用程式傳送 Apple 事件」 | 在自動化列表裡依目標應用程式逐項核准 | 建議搭配最小權限瀏覽器設定檔 |
| 檔案與資料夾（下載/桌面等） | 讀取工程樹、寫入產物 | 路徑在 Finder 裡明明存在卻回傳 ENOENT | 明確授予資料夾；除非政策強制否則避免 blanket 完整磁碟取用 | 把儲藏庫放在 ~/Developer 可縮小授權範圍 |
| 麥克風 / 相機 | 語音喚醒、會議機器人 | 系統立即彈出視窗或擷取裝置列表為空 | 用 QuickTime 做一次測試以觸發首次提示 | 純文字代理常可跳過——仍應在文件中標明「未使用」 |
七步授權順序（請勿重排）
- 預留圖形視窗：以螢幕共享連線或現場 KVM，確保有人能看見右上角的系統提示。
- 安裝到 /Applications 並刪除其他位置的副本，避免隱私權列表裡出現重複套件項。
- 從 Finder 互動式啟動一次 OpenClaw，不要用
sudo open，以便請求行程與未來 LaunchAgent 一致。 - 依此順序走隱私權與安全性子面板：輔助使用 → 螢幕錄製 → 自動化 → 檔案（按需）→ 麥克風/相機。
- 故意觸發一次會失敗的工具（例如無害截圖），強迫系統在列表中插入應用程式列。
- 重新啟動一次；TCC 快取很黏，重新啟動能區分「快取拒絕」與真實政策。
- 只有到這一步再放入 無人值守排程指南 中的 LaunchAgent，並在
~/Library/Logs或你自選路徑下核對日誌。
LaunchAgent、loginwindow 與「無頭半真半假」
在 launchd 下執行的代理會繼承同一使用者在互動授權後寫入的 TCC 決策。它們不會繼承你在錯誤的 sudo 安裝工作階段裡、以 root 身份點過的核准——於是出現經典分裂：「終端機裡能用，plist 裡掛掉」。若有 UserName 鍵，請與點過「允許」的帳戶嚴格對齊。
遠端 VNC：不進資料中心也能看清彈出視窗
ProxyMac 客戶通常透過加密的螢幕共享連到 mini。對 TCC 來說這一般夠用，前提是暫時關掉過重壓縮（小鎖圖示需要銳利文字）、中途不要有人關掉隱私權視窗，以及避免「遠端套遠端」把標題列縮到無法點的尺寸。位元率與畫質請對照 VNC 說明；並與 SSH 與 VNC 選型指南 一起閱讀，讓工程師在封網期知道何時應退回純 CLI 工作流程。
三個硬數字與下一步該看什麼
- 上文七步 plist 清單與頁面內嵌的 HowTo JSON-LD 一一對應——可直接抄進內部 Wiki 作為驗收標準。
- 每次改權限後建議 tail 的三類日誌：代理自有日誌、
log stream --predicate 'subsystem == "com.apple.TCC"'（限定到你的測試時間窗），以及安全團隊已在採集的/var/log/system.log片段。 - 五個區域意味著你可能每台裸金屬都要重複一次入職式設定——清單可以指令碼化，但點「允許」不要指令碼化，既脆弱也違背蘋果的設計意圖。
常見問題
能否僅透過 SSH 授予螢幕錄製？ 不能——多項提示必須在圖形工作階段出現。請先用 VNC 完成一次，再回到 SSH。
複製磁碟後權限為何壞了？ TCC 把核准綁在套件 ID 與簽章上；複製或漂移建置需要重新授權。
LaunchAgent 是否繼承同一套 TCC？ 同一使用者引導工作階段下可以；UID 不一致或 root 無 GUI 時不行。
TCC 搞定後，為何 ProxyMac 上的 Mac mini 仍是 OpenClaw 的合適載體
代理的可信度取決於底下的硬體隔離。專用 Apple Silicon M4 Mac mini 提供 arm64 原生瀏覽器、可預測的單租戶 CPU 以支撐並發工具呼叫，以及蘋果框架預設假設的同一套 macOS 堆疊——於是螢幕錄製開啟時，你擷取的是真實 Metal 表面，而不是蹩腳的 x86 模擬差異。把機器放在 香港 / 日本 / 韓國 / 新加坡 / 美國 可與業務已呼叫的 API 同區域共置；ProxyMac 的 SSH 與 VNC 存取模型也貼合平台團隊偵錯 TCC 的習慣：shell 看日誌，GUI 點同意。租賃相對自購把資本支出變成有時間邊界的實驗，特別適合 2026 年可能每月調整方向的代理試點。
