GitHub 官方文件指出，ephemeral 自託管 Runner 完成一個工作後會自動註銷；這不代表承載它的 Mac 已清除。可信且穩定的工作，可在權限與清理邊界明確時評估常駐模式；外部或高權限工作，應優先評估一次性 Runner，並自動化清理或重建環境。GitHub 對自託管 Runner 的說明
本週建議動作：先抽查工作流程觸發條件、Secrets 權限與任務結束後的主機記錄，再決定 Runner 是否重複使用。
適合負責自託管 Mac Runner 機群、需要選擇節點生命週期的 IT 負責人。
也適合管理 iOS/macOS CI 安全邊界的平台工程師，以及評估建置資源與維運責任的技術總監。
GitHub Actions 自託管 Mac Runner 的信任邊界
Runner 位於同一個組織或儲存庫，不足以證明送進來的工作可信。判斷時應看程式碼來源、觸發事件、可用權限與是否涉及發布，而不是只看 Runner 標籤。
GitHub 提醒，自託管 Runner 可能受工作流程執行的程式碼影響；外部貢獻者的程式碼因此不宜在帶有敏感憑證、內網存取權或其他工作殘留的主機上執行。官方安全使用建議
需特別檢查 pull_request_target。此事件會在基礎分支的信任上下文執行；若工作流程再取出並執行未受信任的提取要求程式碼，風險會升高。官方文件列出這類使用方式的安全注意事項，應依實際工作流程逐項核對，而非只靠事件名稱判斷。pull_request_target 安全說明
任務隔離取決於 Mac 主機生命週期
一次性 Runner 的核心差異，是完成工作後註銷，不再以原 Runner 身分接收後續工作。常駐 Runner 則可能繼續使用相同主機、工作目錄與工具鏈。這只是 Runner 生命週期差異，不是主機資料清除保證。
| 決策指標 | 常駐 Runner | 一次性 Runner |
|---|---|---|
| Runner 註冊 | 可重複接收工作；須管理持續在線的註冊狀態 | 工作完成後註銷；須確認新 Runner 的建立與註冊流程 |
| 工作目錄與本機狀態 | 可能保留前次工作產生的檔案、快取或模擬器狀態 | 若沿用同一台 Mac，仍可能留下主機層資料 |
| 工具鏈與快取 | 保留環境較方便，但版本漂移及殘留須持續管理 | 可重建一致基線；重建流程須可驗證 |
| 憑證與網路資源 | 必須限制後續工作可讀取的 Keychain、檔案及內網資源 | 註銷不會自動撤銷主機上的憑證或清除網路存取設定 |
| 調查與恢復 | 主機仍在，較容易檢查故障現場，但也須管理長期日誌 | 主機銷毀前須先轉存記錄，否則難以還原問題 |
重要區分：任務完成、Runner 註銷、主機清理及乾淨環境重建，是不同的控制點。只有清理記錄或重建驗收能證明主機狀態；Runner 已移除本身不是隔離證據。GitHub 移除自託管 Runner 的說明
企業實作 GitHub Actions ephemeral runner 時，應確認一次性註冊後，承載環境究竟會被清理、重置，還是直接銷毀並重建。若只是移除 Runner 註冊，下一個工作仍可能遇到舊工作目錄、建置產物或使用者層狀態。
憑證風險要按工作流程權限核對
Mac CI 環境隔離不能只靠 Runner 群組或人工核准。應確認每個工作流程可取得哪些 Secrets、GITHUB_TOKEN 權限、簽名身分與內網資源，再追查工作完成後它們是否仍留在主機上。
GitHub 提供設定 GITHUB_TOKEN 權限的方式；工作流程可按所需權限收斂，而非預設給予不必要的寫入能力。GITHUB_TOKEN 權限說明 Secrets 則須依工作流程和環境的使用範圍管理，並檢查是否被寫入檔案、診斷記錄或建置產物。GitHub Secrets 管理文件
可先從工作流程權限開始縮小暴露面：
permissions:
contents: read
這段設定只是權限收斂示例，不代表所有工作都只需讀取權限。若發布或簽名步驟需要額外權限，應只在相應工作流程或受保護環境中授予，並核對部署環境的審核與保護規則。部署環境與保護規則文件
Mac Runner 憑證安全還要包含 Keychain：檢查簽名身分由哪個使用者工作階段載入、工作完成後如何撤除，以及後續工作能否再次讀取。若無法證明憑證已清除或存取已撤銷，就不應讓不可信工作與持有簽名憑證的工作共用主機。
工具鏈一致性需要驗收，不宜猜測效能
常駐 Mac 可保留 Xcode、依賴與快取，方便持續建置；代價是工具鏈可能逐漸偏離基線，工作區、模擬器狀態及舊產物也需要定期檢查。一次性環境則有機會按固定流程重建，但如果安裝步驟、映像或依賴來源未受控，重建不一定代表環境一致。
驗收時應記錄 Xcode 版本、依賴鎖定檔、工作目錄清理結果及 Simulator 狀態。不要以 Runner 類型推斷構建速度或穩定性；只有在相同專案、相同工具鏈與一致條件下的實測，才足以支持效能比較。
按順序完成環境驗收
- 先分類工作。標記外部提取要求、一般合併檢查、簽名發布及需要內網存取的任務，逐類確認信任來源與所需權限。
- 再檢查觸發條件。檢閱工作流程事件、分支保護及倉庫權限；對外部程式碼，不要因 Runner 隸屬同一組織便直接視為可信。
- 收斂憑證。列出 Secrets、
GITHUB_TOKEN、Keychain 身分及網路資源，確認每項只在必要的工作流程中可用。 - 演練任務結束清理。在測試工作後檢查工作目錄、建置產物、使用者層資料及 Simulator 狀態；記錄執行結果與負責人。
- 驗證重建與恢復。若採一次性模式，確認舊環境如何重置或銷毀、新環境如何依基線建立，並測試建置失敗時能否重現。
- 最後檢查日誌。在清理或銷毀主機前，將 Runner 診斷記錄存放到受限制的外部位置，並確認故障排查人員仍可取得。
GitHub 的監控與故障排查文件說明了 Runner 日誌與診斷資料的檢查方向；若一次性 Runner 所在環境會被刪除，應先規劃日誌轉存，避免清理後失去調查材料。自託管 Runner 監控與故障排查文件
可把驗收狀態整理成類似以下記錄，並以實際執行結果取代示例文字：
Runner 註銷：已核對
工作目錄清理：待驗收
Keychain 憑證處理：待驗收
外部診斷記錄：已封存
承載環境重建：未演練
用工作負載與運維責任決定模式
| 工作負載或條件 | 優先評估 | 上線前必要證據 |
|---|---|---|
| 可信、穩定且工具鏈變動少的建置 | 常駐模式 | 權限收斂、工作區清理、定期基線檢查及故障恢復流程 |
| 外部程式碼或不可信輸入 | 一次性模式 | 任務後清理或主機重建紀錄、憑證隔離及網路邊界 |
| 持有簽名憑證的發布工作 | 一次性或專用隔離環境 | Keychain 存取限制、環境保護設定、憑證撤除證據 |
| 無法確認任務後主機狀態 | 暫不視為已隔離 | 先補上清理驗收或乾淨環境重建，再開放後續工作 |
若採常駐模式，團隊須承擔工作區清理、工具鏈維護、長期憑證管理與故障恢復責任。若採一次性模式，則須承擔環境建立、自動註銷、主機清理或重建、診斷記錄轉存及重建失敗處理。無法證明底層環境乾淨時，不應只憑一次性註冊宣稱任務已隔離。
常見問題
一次性 Mac Runner 和常駐 Runner 有什麼差別？
一次性 Runner 完成單一工作後會註銷；常駐 Runner 可反覆接收工作，較容易保留工具與快取。兩種方式都不能單靠註冊狀態判斷 Mac 主機是否清潔，仍須檢查工作目錄、憑證和環境重建紀錄。
Mac Runner 完成工作後，是否仍要清理主機？
若主機會繼續承載其他工作，就要核驗清理或重建結果。註銷 Runner 不會自動證明工作目錄、Keychain、建置產物或 Simulator 狀態已清除。應保留可追查的清理記錄，並確認後續工作無法讀取前一工作留下的資料。
怎樣降低不同 Mac CI 工作之間的憑證風險？
先按工作流程限制 Secrets 與 GITHUB_TOKEN 權限，再核對簽名身分、Keychain 和內網資源的存取範圍。任務結束後檢查憑證是否撤除；不要把人工核准或 Runner 分組當成主機隔離的替代證明。
哪些 iOS CI 工作適合採一次性 Runner？
外部貢獻程式碼檢查、高權限發布及不宜與其他工作共用憑證或工作目錄的任務，可優先評估一次性 Runner。前提是清理或重建承載環境的流程可驗證，且診斷記錄已在環境銷毀前轉存。
若目前用一台共享常駐 Mac 承載所有工作，工作區殘留與憑證檢查容易累積成人工責任；若替每位開發者各自採購設備，則會增加硬體管理與版本維護工作，而一般非 Mac 建置環境不能直接取代 Xcode 與 macOS 工作負載。對需要短期或可調整建置資源、又不想自行維護實體設備的團隊，NodeMini 遠端 Mac 可作為評估選項；但應先確認實際交付、連線方式與環境清理責任，不能把遠端存取等同於隔離保證。可先查看NodeMini 遠端 Mac 服務概覽，再核對NodeMini 遠端 Mac 的服務資料；若工作負載長期固定、重度且必須使用實體介面，則自購專用 Mac 可能更合適。