Runner 重開後沒有接下新工作，但主機看起來仍可連線。
判斷：不適合把 macOS 自動登入當成預設安全設定。 GitLab Runner 在 macOS 的服務模式會依賴使用者工作階段；啟用前應核對 FileVault 要求、執行帳號權限與作業信任範圍。若控制措施不符合安全政策，應調整節點與任務邊界，不要只為維持 Runner 在線而降低保護要求。
適合企業 IT 負責人：確認 Mac CI 節點重啟後的恢復方式是否符合終端政策。
適合平台工程師：核對 Runner 服務模式、實際執行帳號與建構任務邊界。
適合安全負責人：檢查自動登入、FileVault、Keychain 與不可信程式碼的組合風險。
00先確認使用者工作階段與 Runner 狀態
為何 macOS Runner 會受使用者登入工作階段影響？
GitLab 說明，macOS Runner 可作為使用者層級的 LaunchAgent 運行；這類服務與登入的使用者工作階段相關。自動登入可能用於重啟後恢復工作階段，讓 Runner 重新可用，但它只處理登入條件，不能證明服務設定正確、工作已能執行，或主機已符合安全要求。請對照GitLab 的 macOS Runner 服務安裝說明和macOS 環境設定文件確認實際模式。
驗收時要把以下狀態分開記錄，不能把「主機可連線」直接當作「CI 已恢復」：
| 狀態 | 要核對的證據 | 不能據此推定 |
|---|---|---|
| 磁碟已解鎖 | 開機後是否完成磁碟解鎖，以及是否符合組織的加密政策 | 使用者已登入 |
| 使用者已登入 | 目標帳號的桌面工作階段是否存在 | LaunchAgent 正常運行 |
| LaunchAgent 已載入 | 服務是否以預期帳號啟動，設定是否指向正確 Runner | Runner 已能接收工作 |
| Runner 在線 | 控制端狀態及節點端服務紀錄一致 | 建構、測試或簽章工作成功 |
| 代表性工作成功 | 受控測試工作完成，且輸出與紀錄可核對 | 不同信任來源的工作已隔離 |
架構分析：自動登入只會改變使用者工作階段的恢復方式，並不會自動修復 Runner 註冊、服務設定或工作環境。企業若採用此方式，應在隔離測試節點執行重啟測試，逐項記錄上述狀態及負責處理失敗的人員。
01盤點執行帳號的權限範圍
Runner 執行帳號能接觸到的資源，才是判斷節點風險的實際起點。請從帳號與作業紀錄確認它可讀取哪些專案目錄、使用哪些開發工具、存取哪些網路服務，以及能否讀取使用者資料或修改系統設定。只查看 Runner 設定檔，無法替代對實際作業身份的核驗。
對照任務需求檢查帳號是否擁有不必要的管理權限；如果建構或測試工作只需一般使用者權限，就不應為了省去權限問題而直接擴大權限。將檢查結果記錄為「必要權限、核准依據、可讀取資源、例外項目」，並以實際作業執行身份和紀錄佐證，而不是只依賴團隊口頭說明。
02劃清 Shell executor 與不同專案的邊界
Shell executor 能否隔離不同專案？
不能假設它會自動隔離不同專案。GitLab 文件指出，Shell executor 會在 Runner 主機上執行作業，隔離能力有限；因此，作業可觸及的主機資源與執行帳號權限必須一併評估。此限制是針對 Shell executor 的說明，不應延伸成所有 executor 都具有相同風險。可參閱GitLab Shell executor 的安全說明。
| 作業來源與信任程度 | 節點安排建議 | 放行前要確認 |
|---|---|---|
| 受控、可信的內部建構工作 | 可評估共用節點，但要限制帳號權限與可讀取資源 | 專案分配規則、執行身份及工作紀錄 |
| 外部貢獻或尚未審核的程式碼 | 不應與持有發布憑證的工作共用同一信任邊界 | 是否能觸及主機檔案、網路與憑證 |
| 不同信任等級的專案 | 視風險拆分 Runner 或承載節點 | 分配規則能否阻止不合適的工作落到敏感節點 |
以上是依 Shell executor 執行位置與隔離限制作出的架構建議，不是 GitLab 對每個企業環境的固定部署要求。若團隊無法證明不可信程式碼與敏感資源隔離，應先拆分承載或調整 Runner 分配，再考慮共用主機。
03核對 FileVault 與重啟後的登入條件
FileVault 啟用時，Runner 能否在重啟後自動恢復？
不能只根據 Runner 的在線紀錄作出保證。Apple 說明，在啟用 FileVault 的情況下，自動登入設定可能無法使用；實際恢復結果須依裝置設定與組織政策測試。請查看Apple 關於 Mac 自動登入設定的說明及FileVault 管理文件，並以企業裝置上的實測為準。
不要為了讓 Runner 開機後自動接單，就擅自關閉組織要求的磁碟保護。先確認磁碟解鎖、使用者登入、LaunchAgent 載入及 Runner 在線各自的條件；若安全政策與登入恢復方式衝突，應由安全與平台團隊共同決定是否改用人工恢復、調整節點用途或重新設計工作分配。
04管理 Keychain 與簽章憑證的可讀取範圍
iOS 簽章憑證和 Keychain 應放在哪類 Runner？
應放在經核准、且信任邊界能滿足簽章需求的建構環境中，不能因為一般測試工作共用同一帳號，就讓所有作業都能讀取發布憑證。先盤點 Runner 帳號能存取的 Keychain、憑證、私密金鑰及發布憑證，再確認哪些工作確實需要它們。
將簽章工作與一般編譯、測試工作分開驗收：限制可執行簽章工作的專案與來源，檢查憑證使用紀錄，並確認工作結束後不會把敏感材料留在可被後續作業讀取的位置。這是依最小權限與 Shell executor 主機執行特性提出的架構建議；若無法證明工作來源可信、帳號權限受限且使用紀錄可追查，就不應在共用節點放行敏感簽章工作。
05以重啟測試與證據清單決定是否放行
測試應在隔離環境進行，使用不含正式發布憑證的代表性工作；確認恢復流程後，再由安全與平台負責人審核是否能進入正式環境。若執行至任何一項無法提供證據，應暫緩放行或縮小節點用途。
- [ ] 記錄 Runner 的服務模式、LaunchAgent 所屬帳號與預期啟動條件。
- [ ] 核對實際作業身份，列出它可讀取的目錄、工具、網路資源及管理權限。
- [ ] 標記各專案與工作來源的信任等級，確認 Runner 分配規則不會讓未審核工作接觸敏感節點。
- [ ] 依組織政策確認 FileVault 狀態與自動登入限制；不得以關閉必要的磁碟保護作為未經核准的恢復手段。
- [ ] 列出 Keychain、簽章憑證及發布資料的讀取權限，並核對使用紀錄是否可追查。
- [ ] 在隔離節點重啟，分別記錄磁碟解鎖、使用者登入、Runner 狀態與代表性建構結果。
- [ ] 指定恢復失敗時的處置責任、人工介入方式及暫停接收工作的條件。
實際測試時，先以低風險工作確認使用者工作階段與 Runner 狀態，再執行代表性建構；兩者都通過，才進入正式放行評估。若登入成功但 Runner 未接單，或 Runner 在線但工作失敗，應分別調查服務狀態與作業環境，不要用一次成功的登入畫面代替完整驗收。
對企業而言，個人開發機兼作建構節點，容易遇到使用者離線時工作中斷、工作與個人資料混在同一環境，以及憑證權限不易集中審核等問題；自購專用 Mac 可增加控制權，但仍須自行負責維護、恢復測試與節點管理。若需求是限期試跑、短期擴充或建立獨立測試環境，租用遠端 Mac 可能比把工作長期塞進開發者的日常設備更合適；但需要長期固定負載或實體周邊的團隊，仍應評估自購。評估 NUKCLOUD 時，可先檢視服務資訊，再透過支援說明核對實際提供的存取方式、登入恢復條件與交付資料，並以本文清單逐項驗收。