2026 年 10 月，Hacker News 上一則關於 Codex CLI 預設安裝常駐背景 daemon 的討論拿到四百多個讚。許多使用者回報：安裝一個命令列 AI 工具，卻在不知情的情況下多了一個會自動更新、長期駐留的背景服務。同一時間，Kodama、Paseo 這類「自架、透明的 coding agent daemon」專案也開始出現——需求是真的，但交付方式決定了信任。

快速結論

常駐 daemon = 隱形的授權擴張，安裝前先看清楚

傳統 CLI

你不叫它，它不動。結束就結束，沒有殘留。

常駐 daemon

一直活著：佔記憶體、保持連線、接收你沒審過的自動更新。

務實立場

可以常駐，但要明說、要好關、要可稽核。預設偷裝是信任消耗。

為什麼要在意背景常駐？

把 AI CLI 裝在工作機上，和裝一個計算機 App 不一樣。常駐進程意味著三件事：資源（記憶體與 CPU 被持續佔用）、網路（它可能長時間保持對外連線、回傳遙測）、供應鏈（自動更新讓「你今天信任的版本」和「明天跑在你機器上的版本」之間沒有稽核點）。

10 月的 Codex CLI 爭議之所以爆開，正是因為「預設安裝、不明示、自更新」三件事疊在一起。功能本身（預熱、快啟動、背景任務）不是問題，姿態才是問題：opt-out 設計把決策成本轉嫁給使用者，而行為經濟學早就證明預設值就是事實上的決策。

第一步：盤點你的機器上有什麼在跑

不管裝過哪一家的 AI CLI，先花五分鐘做一次盤點。

macOS

  • 列出 launchd 管理的使用者服務：launchctl list | grep -i -E 'codex|claude|openai|anthropic|copilot'
  • 看常駐代理的定義檔：ls ~/Library/LaunchAgents/，有疑慮的 plist 用 cat 看它啟動什麼二進位檔。
  • 即時觀察：打開「活動監視器」，按 CPU 或記憶體排序，搜尋工具名稱。

Linux

  • 使用者級服務：systemctl --user list-units --type=service | grep -i -E 'codex|claude'
  • 系統級服務：systemctl list-units --type=service --state=running | grep -i -E 'codex|claude'
  • 看開機自啟：systemctl --user list-unit-files --state=enabled

網路連線

想確認誰在對外連線，macOS 可用 lsof -i -P | grep -i -E 'codex|claude'，Linux 可用 ss -tup | grep -i -E 'codex|claude'。看到不認識的常駐連線，先查清楚再決定保留或移除。

Codex CLI：背景 daemon 的關閉與管控

依 HN 討論串與官方 issue 的說明，Codex CLI 在安裝時預設放置一個持久、自更新的背景 daemon。務實的處理順序：

  1. 先確認存在：用上面的 launchctl / systemctl 命令確認 daemon 是否在你的機器上運行。
  2. 停用：macOS 用 launchctl bootout gui/$(id -u) ~/Library/LaunchAgents/<plist 名稱> 或直接移除對應 plist 後重新登入；Linux 用 systemctl --user disable --now <服務名>。
  3. 保留 CLI 本身：停用 daemon 不影響你手動呼叫 CLI；失去的是背景預熱與自動更新，換來的是每一次執行都是你明確觸發的版本。
  4. 更新改為手動：固定在你方便的時間用套件管理器更新，更新前看一下 changelog，等於幫自己加一個稽核點。
原則：「可以常駐，但要明說、要好關、要可稽核。」如果一個工具把關閉路徑藏起來，或關掉就拒絕運作，這本身就是一個評分訊號。

Claude Code 與其他工具的行為盤點

Claude Code 主要以「你啟動才存在」的 CLI 模式運作，但任何會跑背景任務、檔案監聽或自動續期的功能，都值得用同一套方法檢查：它有沒有在你不看的时候保持活著？有沒有自動更新？更新前能不能看 changelog？

GitHub Copilot CLI、各種 IDE 內嵌 agent 也一樣。IDE 擴充尤其容易忽略：它們常內建自動更新通道，重開編輯器就悄悄換了版本。建議每季做一次「AI 工具大盤點」：列出所有 AI 相關進程、LaunchAgents、systemd units、IDE 擴充，逐一確認「我知道它在、我同意它在」。

想要背景 agent？自架是更透明的路

背景跑 coding agent 的需求本身完全合理——讓 AI 在你睡覺時修 issue、跑測試。爭議不在功能，在誰掌控。Kodama、Paseo 這類開源自架 daemon 的思路是：同一個功能，用你看得見、關得掉、讀得懂程式碼的方式交付。如果你確實需要常駐 agent，自架方案讓「常駐」變成你的選擇，而不是供應商的預設值。

安裝任何 AI CLI 前的四問

  1. 有沒有常駐進程？安裝文件或 issue 區搜 daemon、background、service、agent。
  2. 有沒有自動更新？更新前看不看得到 changelog？能不能關掉自動更新、改為手動？
  3. 收集什麼遙測？預設開還是預設關？退出機制（opt-out）在哪？
  4. 關閉路徑在哪？是一個 setting，還是要手動砍 daemon？文件裡有沒有寫？

四問都答得出來的工具，通常也把信任當一回事。答不出來的，就把它當「外圈訪客」：跑在容器或專用帳號裡，別讓它住在你的工作機上。

常見問題

常駐 daemon 一定是壞事嗎？

不是。預熱、快啟動、背景任務都是真實的體驗收益。問題從來不是功能，而是告知與控制權：明說、好關、可稽核的常駐，和預設偷裝、關不掉、自動更新沒有稽核點的常駐，是兩種完全不同的產品姿態。

關掉 daemon 會讓 Codex CLI 不能用嗎？

一般情況下 CLI 的本體功能不受影響，你失去的是背景預熱帶來的啟動速度與自動更新。對大多數人，這是划算的交易：每一次跑的都是你明確更新的版本。

公司配發的機器上裝 AI CLI，誰該管這件事？

這已經是 IT 治理問題。建議團隊把「AI 工具安裝行為盤點」寫進資產與權限管理：哪些工具允許常駐、遙測政策是什麼、更新通道怎麼管。個人警覺補不了制度偷懶的洞。

我真的需要背景跑 agent，又不想用官方 daemon，怎麼辦？

看開源自架方案（例如 Kodama、Paseo 這類專案），或把官方 CLI 關進容器與專用帳號，用你自己的排程系統（cron、systemd timer）決定它什麼時候活、什麼時候關。掌控權在你手上，常駐就從風險變成功能。