macOS 登入死機事故：LumaReader 與 LaunchServices 復原紀錄
記錄一次由檔案關聯與圖示整合操作後發生的 macOS 登入卡死，包含證據、復原過程、因果限制與後續防護。
macOS 登入死機事故：LumaReader 與 LaunchServices 復原紀錄
2026 年 9 月 2 日，主力 Mac 在 Codex 協助安裝 LumaReader、設定 Markdown 預設開啟程式及 Finder 文件圖示後，先出現 Finder 與背景應用程式無法正常開啟，重新啟動後則停在登入載入畫面。安全模式、磁碟修理工具及一次保留資料的 macOS Tahoe 重裝都沒有恢復登入；最後在 macOS Recovery 反向處理使用者層 LaunchServices 狀態、圖示快取、重複 App 與專案索引後，重新啟動即恢復正常。
這起事件沒有證據顯示 SSD 或主機板損壞，也沒有清除使用者資料。然而它確實讓主力電腦一度無法使用，已達嚴重事故等級。這份紀錄不是要證明「所有 Codex 操作都危險」，而是說明：當 Agent 有權操作主機系統服務時，錯誤的持續重試與過大的變更範圍，足以造成接近整機故障的實際後果。
可重用的操作規範與提示詞整理在 Systems/safe system operations with agents。
事故範圍與目前結論
| 項目 | 結果 |
|---|---|
| 影響 | Finder 失效、背景 App 無法正常開啟、重新開機後無法完成使用者登入 |
| 資料 | 使用者資料與 Codex 本機紀錄仍存在，沒有抹除磁碟 |
| 硬體 | SMART Verified；APFS Volume、Container 與實體 SSD 的 First Aid 均通過 |
| 磁碟空間 | 仍有約 74–75 GB 可用，排除「磁碟完全塞滿」 |
| 非清除重裝 | 完成 Tahoe 重裝後仍無法登入 |
| 最後復原 | 重設使用者層 LaunchServices 狀態、清除相關快取、停止專案索引並停用兩份 LumaReader 後成功登入 |
| 根因可信度 | 高度懷疑與 Codex 當輪系統整合操作相關；主觀可信度約 85%，不是單一變因的鑑識定案 |
「約 85%」是根據時間關聯、Codex 工作紀錄、系統症狀與復原結果做出的工程判斷。因為最後一次復原同時調整四項相關狀態，現有證據無法證明其中某一項是唯一根因。
當時要完成的工作
原始需求本身很合理：
- 安裝最新 LumaReader，僅保留一份上一版本備份。
- 讓
.md、.markdown、.mkd與.mdx可由 LumaReader 開啟。 - 將 Markdown 設為預設由 LumaReader 開啟。
- 讓 Finder 顯示 LumaReader 的文件圖示。
真正的問題不是產品需求，而是執行方式逐步跨出 App bundle 與專案範圍，進入了使用者登入環境依賴的 LaunchServices、Finder 與 iconservices，且沒有在第一個異常訊號出現時停止。
可確認的事件時間線
1. 系統逐步失去反應
- Codex 工作仍在進行時，背景應用程式開始打不開。
- Finder 隨後也無法正常開啟。
- 等待後未恢復，使用者關機。
- 再開機可以到登入畫面，但輸入密碼後一直停在載入狀態。
2. 安全模式沒有成功進入桌面
Apple Silicon 安全模式完成 FileVault 與帳戶驗證後，只看到黑畫面與滑鼠游標；稍後出現彩色轉圈圈，仍無法進入桌面。這表示問題不只是一般第三方登入項目，但當時仍不能據此判定硬體損壞。
3. Recovery 排除磁碟與容量問題
在 macOS Recovery 中確認：
- Data Volume 因 FileVault 鎖定而一度未掛載，解鎖後可正常讀取。
- SSD 與 APFS 結構的檢查結果正常。
- 可用空間仍有約 74–75 GB。
- 使用者檔案及 Codex 的本機資料庫、工作階段與設定仍存在。
4. 保留資料的 Tahoe 重裝無效
第一次選擇的是「重新安裝 macOS」，不是抹除磁碟。安裝完成後，登入畫面仍持續轉動而無法進入桌面。
這個結果很重要：非清除重裝會替換系統檔案，但保留使用者帳戶、偏好設定、第三方 App 與大量使用者層狀態。如果故障來源正是這些被保留的資料，重裝系統本身不會消除問題。
5. 回查 Agent 最後的系統操作
原 Codex 工作階段顯示，當輪曾進行或嘗試：
- 安裝及驗證正式 LumaReader App。
- 同時保留正式版與一份可執行的 Backup App。
- 註冊、取消註冊與整理 LaunchServices 的 App 紀錄。
- 直接更新 Markdown handler 偏好。
- 重啟使用者層
lsd與 Finder。 - 建立 Swift 工具讀寫預設 handler。
- 在 API 或工具已出現長時間阻塞後，改用另一個工具繼續嘗試。
工作紀錄甚至已明確指出「LaunchServices API 出現阻塞」，但後續沒有啟動停止條件，反而繼續疊加註冊、偏好、快取與替代工具操作。這是整起事件最需要被保留下來的決策失誤。
6. Recovery 中的反向處理
最後一次復原沒有直接刪除個人資料，而是採用可回復的方式：
- 把使用者 LaunchServices 的 secure preferences 改名保留，讓系統下次登入重新建立。
- 清除可由系統重建的 LaunchServices 與 iconservices 使用者快取。
- 將 LumaReader 專案暫時改成
.noindex，避免 Finder 與系統服務繼續掃描專案內的 App bundle。 - 將
/Applications中的正式版與 Backup 版改為非.app結尾，暫時停止兩者被辨識與註冊。 - 重新啟動，第一次就成功進入桌面。
四項變更是在同一次重新啟動前完成，因此不能把成功完全歸因於其中一項；它們共同移除了同一組 App 身分、檔案關聯與圖示索引風險。
最可能的事件鏈
Agent 處理 .md 預設程式與 Finder 圖示
→ 兩份相同產品身分的可執行 App 同時存在
→ LaunchServices 已阻塞，Agent 仍更換工具並繼續寫入、註冊與刷新
→ Finder／lsd／iconservices 進入不一致或長時間等待
→ 強制關機可能中斷尚未完成的使用者層狀態更新
→ 後續登入持續讀取相同偏好、快取與 App 登錄，因此再次卡住
→ 非清除重裝保留這些資料，所以沒有解決
→ 反向移開偏好、快取、索引來源與兩份 App 後恢復
這個鏈條是目前最符合全部證據的解釋，但仍屬因果推論。完整鑑識若要提高可信度，還需要當時所有 shell command、臨時 Swift／zsh 原始碼與相關系統 log。
技術上曾被過度簡化的一件事
「預設開啟程式」與「Finder 文件圖示」有關，但不是同一件事：
- 預設程式決定雙擊文件時由哪個 App 開啟。
- 文件圖示還取決於 App 是否在
Info.plist正確宣告文件類型、角色、UTI 與實際存在的.icns資源。 - Finder 與 LaunchServices 何時重新整理，也不等於可以安全地反覆清除快取或重啟服務。
較好的順序應該是先在未安裝的 App bundle 中檢查宣告與資源，再到測試帳戶或可還原環境驗證安裝；主力帳戶最後只做一次使用者可見、可撤回的預設程式設定。
哪些處理有用，哪些沒有
| 處理 | 結果 | 判讀 |
|---|---|---|
| 等待一般登入 | 無效 | 不是單純載入較慢 |
| 安全模式 | 無效 | 問題仍會影響使用者登入環境 |
| 確認空間與 First Aid | 沒有直接修好，但有必要 | 排除磁碟塞滿、可辨識的 APFS／硬體異常 |
| 非清除重裝 Tahoe | 無效 | 使用者層偏好、快取與第三方 App 被保留 |
| 回查 Agent 最後操作 | 有效 | 將範圍縮小到 LaunchServices 與 LumaReader 登錄 |
| 解鎖 Data 並確認資料 | 有效 | 確認可以先備份，避免不必要的抹除 |
| 可回復地移開相關狀態 | 與恢復直接相連 | 移除偏好、快取、索引來源及重複 App 後成功登入 |
如果再次遇到相似症狀
這不是一份可以逐字複製 Recovery 指令的教學。磁碟識別碼、Volume 名稱與使用者路徑每次都可能不同，錯誤照抄 diskutil、rm 或 mv 可能造成新的資料損失。安全順序應是：
- **停止 Agent 當前工作。**不要讓它在異常服務上自動重試其他工具。
- **不要立刻強制關機。**若系統仍可操作，先保存文件、備份專案與 Agent 本機紀錄。
- **先做唯讀診斷。**確認磁碟空間、程序狀態、最近變更與是否出現重複 App 身分。
- **保留證據。**記下時間、命令、程序、錯誤與已做變更；不要一邊清理一邊失去根因線索。
- **必要時進 Safe Mode 或 Recovery。**先辨認並解鎖正確 Data Volume，再備份重要資料。
- **優先改名或移開，不直接刪除。**每次只處理一個已確認的來源，並保留還原名稱。
- **重開機前列出所有變更。**如果多項同時處理，事後必須承認無法確定單一有效因素。
- **硬體與檔案系統檢查正常時，不急著抹除磁碟。**先確認是否為被非清除重裝保留的使用者層狀態。
如果資料尚未備份、路徑無法確認或 FileVault 狀態不清楚，應停止並尋求 Apple 或熟悉 macOS Recovery 的人員協助。
這次對 Agent 協作的核心修正
事故不是因為 Agent 擁有自由度，而是因為自由度沒有搭配影響範圍、單步交易與熔斷條件：
- 使用者同意目標，不等於同意任何達成手段。
- 工具得到系統權限，不代表當下操作仍然安全。
- 第一個核心服務阻塞是停止訊號，不是更換工具繼續嘗試的理由。
- 設定、快取、服務重啟與替代工具不可在同一個失敗鏈中連續疊加。
- 主力機上的系統整合應先在測試帳戶、測試機或可還原環境驗證。
- 一般專案內開發、測試與可回復修改仍應讓 Agent 自主完成；只有主機全域影響升高時才提高門檻。
後續狀態
事故整理時，Mac 已能正常登入，Finder 與 Codex 本機紀錄均恢復；LumaReader 及其 Backup 仍保持停用，Markdown 關聯也已重設。後續若重新處理 LumaReader 系統整合，應先完成獨立備份，只保留一份可註冊的 App，並依 Systems/safe system operations with agents 的分區與停止條件執行。
資料來源與公開邊界
本頁依據使用者於 2026 年 9 月 2–3 日整理的事故紀錄、Recovery 畫面與原 Codex 工作階段摘要重寫。公開頁保留事件、判斷與方法，但不公開本機帳戶名稱、絕對路徑、私密 Agent 資料結構、憑證或可被誤用的破壞性命令。逐行指令與完整本機狀態仍由離線事故檔保存。