Codex CLI 偷偷装了个”永驻后台守护进程”，开发者炸了

OpenAI 的 Codex CLI 从 0.157.0 版本开始，每次你打开交互式会话都会偷偷启动一个持久后台守护进程——它会自我复制、自我更新、永不退出，而且默认开启。这个 GitHub issue 在 Hacker News 上拿到 404 分，评论区的愤怒程度不像是针对一个 bug，更像是针对一次信任的背叛。

它到底做了什么

发帖人 Yihua-Liu-1997 在 WSL2 上用 npm 安装了 Codex CLI 0.157.0，发现每次打开 codex 交互会话都会触发一系列他完全没有预料到的行为。首先，它启动了一个名为 codex app-server –managed-daemon 的后台进程，这个进程没有 TTY、运行在独立会话中，关闭所有 Codex 窗口后它依然活着——被重新挂到 PID 1 上，一直运行直到你手动执行 codex app-server daemon stop 或者重启电脑。

更让人不安的是第二点：它把整个平台包（约 374 MB，包含 codex 二进制、code-mode-host、bundled 的 bwrap/zsh/rg）完整复制到 ~/.codex/packages/app-server-daemon/releases/ 目录下，然后从那个副本运行守护进程。也就是说，从那一刻起，后台运行的版本和你用包管理器装的 CLI 版本脱钩了。你 npm update 更新 CLI，后台 daemon 还是老版本；daemon 自我更新，你的 CLI 又不知道。

第三点：它启动了一个独立的更新循环进程（pid-update-loop），5 分钟后开始检查更新，之后每小时检查一次，发现新版本就下载并重启后端——而重启会杀掉正在进行中的对话轮次（有另一个 issue #40969 记录了这个问题，60 秒的 drain 预算后强制 kill）。

“CLI 的生命周期应该跟窗口走”

发帖人的核心诉求其实很简单：对于一个命令行工具，最符合直觉的默认行为应该是——后端进程活着是因为窗口开着，窗口关了进程就死；跑的是你包管理器装的那个二进制；不会在后台偷偷更新自己。他说得很克制：”对一个 CLI 来说，最不出乎意料的默认是后端随窗口生死、跑你安装的版本、不在后台自我更新。”

他承认共享的、自我更新的 daemon 对远程控制或桌面应用是合理的，所以可以在那里开启，或者用户显式执行 codex app-server daemon start 时开启。但默认开启？对一个 CLI 工具来说，这就像你装了一个文本编辑器，它默默在你的系统里装了一个自启动服务、每小时检查更新、还会把你正在编辑的文件强制保存。

社区反应：不只是”不方便”

评论区的情绪很快从”这设计有点怪”升级到了”这不可接受”。megahall 说”stuff should not be creating mystery servers and processes all of a sudden on small version number bumps without giving people a heads-up”——小版本号升级突然冒出神秘的服务和进程，事先没有任何通知。kr8vka0z 更直接：”the CLI is unusable until this is fixed。”

zdd 的评论特别有意思：”This is terrible. I can’t input anything on the CLI at all. You should fix this problem as soon as possible and give us 100 banked reset!”——他要求 OpenAI 给 100 个 banked reset（Codex 的对话重置额度）作为补偿。这个细节说明影响范围之广：不是个别用户遇到了问题，是很多人发现 CLI 根本没法用了。

还有一个更深层的技术问题被 aetherxeg-source 点出来了：一旦 CLI 把自己复制到受管目录、后台更新器可以替换那个副本，”服务你后续对话的进程就不再一定是你显式安装或调用的那个 artifact”。他建议 daemon 应该暴露一个”执行回执”，包含客户端 CLI 版本、daemon 二进制摘要、daemon 代际、更新器状态、继承的环境代际，让用户能区分”我跑的到底是谁”。这本质上是一个供应链安全/完整性问题，不只是体验问题。

更大的图景：CLI 工具的边界在哪里

这件事之所以引发这么大争议，不只是因为 Codex CLI 做错了，而是因为它触碰了一个正在变得模糊的边界：CLI 工具到底可以做什么？传统上，CLI 工具是无状态的、一次性的——你调用它，它执行，它退出。Git 不会在你 git commit 之后偷偷启动一个后台进程监控你的仓库；npm 不会在你 npm install 之后每小时检查一次自己有没有新版本。

但 AI 编码工具正在打破这个范式。Codex 需要维持长会话、需要代码执行沙箱、需要跨对话的上下文——这些需求确实需要某种持久化。问题不在于”需不需要 daemon”，而在于”需不需要默认开启”和”需不需要自我更新”。桌面应用有自更新是合理的（用户预期 App Store 会推送更新），但 CLI 工具用户的心智模型完全不同——他们期望的是”我控制什么时候装、什么时候升级、什么时候卸载”。

OpenAI 目前还没有在这个 issue 下回复。从 Nix 社区的反应来看，已经有人打了 patch 把 daemon_auto_start 默认改为 false。如果 OpenAI 不尽快修复，Codex CLI 在 Linux 和 WSL2 用户群体中的信任损耗可能是长期的。

核心观点：AI 编码工具的持久化需求是真实的，但”默认开启自我更新守护进程”越过了 CLI 工具的信任边界。如果你在用 Codex CLI，现在就去 config.toml 里加 daemon_auto_start = false。更深层的问题是：当 AI 工具开始拥有”后台生命”时，开发者社区需要一套新的契约来定义什么行为是可接受的。