电脑上那个 AI 编程助手,关掉窗口还在偷偷运行

10 月 12 日，Hacker News 上一个帖子冲到 400 多分。帖子的主角不是什么新模型，是 OpenAI 的命令行编程工具 Codex CLI 悄悄在你电脑上留了一个常驻后台进程，而这个进程会自己给自己更新版本。

发帖人 9 月 25 日就在 GitHub 上开了 issue，编号 #48195，标题很直白：请求把 daemon_auto_start 改成可选，理由也很朴素，一个常驻后台的自更新守护进程不该是默认行为。

你要是最近用 Codex CLI 写过代码，这段可能说的就是你。

哪里不一样了

变化发生在 Codex CLI 0.157.0 版本，时间是 2026 年 9 月 25 日。那一版的更新日志里，关于这个行为的全部描述是一句话：为符合条件的交互式会话启用自动后台服务器启动。没有提常驻进程，没有提自动更新，也没有给出对应的配置项名字。

换句话说，一个会常驻你电脑、每小时联网检查更新、下载新版本再把自己重启一遍的进程，是这么悄悄上线的。

按 issue 报告者在 Linux 和 WSL2 环境下的观察，具体发生了四件事：

第一，你打开一次交互式会话，就会拉起一个叫 codex app-server --managed-daemon 的进程，它脱离终端独立运行，关掉所有 Codex 窗口之后还在，被系统挂到 PID 1 下面。

第二，它会把整个平台包复制一份，大约 374MB，放到 ~/.codex/packages/app-server-daemon/ 目录下，从这份副本里运行。这么做的直接后果是，它的版本和 npm 装的那个 CLI 不再同步。

第三，还有一个独立的更新循环叫 codex app-server daemon pid-update-loop，启动 5 分钟后检查一次更新，之后每小时检查一次，下载新版本并重启后端。

第四，daemon stop 停不掉这个更新循环。想彻底关掉得手动 pkill。

同样是命令行工具，别人是随叫随到随走，这个是装了之后常驻，还要自己给自己升级。

几个容易忽略的细节

第一个细节是磁盘。有人统计自己的机器上旧版本累计占了约 12GB。另一位发现 ~/.codex/packages/standalone/releases 里每个旧版本都留着，一个二进制约 300MB。还有人在 Bun 的安装缓存里翻出 11 个 codex 相关二进制，同样每个约 300MB。光这一项就是 3.3GB，还不算守护进程那份副本。

第二个细节最让人不安。有用户在 issue 下提到，这个后台进程会保留它第一次启动那个目录的环境变量，direnv 加载的值比如 GH_TOKEN 会被带进你之后在别的项目目录里跑的会话。这是一位用户的单独报告，OpenAI 没有确认，但如果你按目录加载过密钥，值得自己验一下。

第三个细节是它会打断你正在干的活。更新循环重启后端会中断正在跑的任务，这一条有 issue #40969 记录。有用户报告自动更新把 .git 等目录变成只读，直接卡住工作，这条同样没有第二来源确认。

第四个细节是它可能已经开了很久。issue 是 9 月 25 日开的，热榜是 10 月 12 日上的。这意味着从 0.157.0 发布那天起，只要你在 Linux、WSL2 或 macOS 上交互式用过它，这个进程大概率已经在你机器上跑了几周。

需要说清楚的是，374MB、5 分钟和每小时这些数字来自单个用户的观察和 issue 里的描述，OpenAI 官方文档至今没提这个守护进程，这些数字应该当报告看，不当规格看。

这跟你有什么关系

判断标准很简单：看你的机器上是不是有一个关了窗口还在跑、并且能自己升级自己的 AI 工具进程。有的话，这就是你。

第二层是磁盘和带宽。一个常驻进程每小时联网一次，一天就是 24 次检查。这一条对笔记本党和不限量网络的人影响不大，对流量按量计费或者机器性能吃紧的人，值不值得为它花心思自己算。

第三层我想多说一句。这件事让很多人不满的点，其实不是"有守护进程"。很多工具都有后台服务，浏览器、编辑器的语言服务器都是。真正让人不安的是三件事叠在一起：默认开启、没在配置文档里说明、关闭入口藏得深。

一个在你不知情的时候改变了机器状态、还在自动替换自己版本的程序，这是所有开发工具都不该越过的线。不管它是好心的还是偷懒的，知情同意这四个字不能省。

你有没有遇到过被后台进程偷偷占资源或者卡住工作的情况？

你现在能怎么用

第一件事，检查。你在自己常用的机器上跑一遍进程列表，看看有没有 codex 相关的进程在你没打开 Codex 的时候还活着。Windows 用任务管理器，Mac 用活动监视器，Linux 用 ps aux。

第二件事，关掉。issue 里给出的最短解法是一条命令，codex features disable daemon_auto_start。这条命令来自 issue 和 HN 讨论，OpenAI 的 CLI 官方文档里没写。另一条路是改配置文件，在 ~/.codex/config.toml 里把 daemon_auto_start 设成 false，多个用户确认这样也有效。

第三件事，清残留。真要关干净，光停服务不够，更新循环还在。issue 报告者给的完整组合是三条，codex features disable daemon_auto_start、codex app-server daemon stop、pkill -f 'app-server daemon pid-update-loop'，再删掉 ~/.codex/packages/app-server-daemon 目录。删之前先确认这个目录里没有你自己放的东西。

第四件事，验证一下密钥。有按目录加载环境变量的习惯的，跑到别的项目目录里试一次，确认 token 没被带过去。这一步花不了两分钟，但出问题的代价比两分钟大得多。

我的看法

截至 10 月 13 日，issue #48195 还开着，页面上除了机器人加的标签，没有 OpenAI 维护者的正式回复。

不过 OpenAI 确实在修。10 月 8 日发布的 v0.162.0 一口气合并了六项守护进程相关的修复，从跳过 Windows 挂载目录自启动到更新失败重试都在改。这说明摩擦是真的密集，只是修的方向是让它别出错，不是让它先问你一句。

我更在意另一件事。上期 OpenAI 才因为智能体逃出沙箱而暂停训练，这期它自己家的命令行工具又因为常驻自更新被顶上热榜。这两件事的性质完全不同，但指向同一个位置：工具在替你做决定，而且决定得比你快。

对普通开发者来说，记住一条就够了。任何在你不知情的时候长期驻留、并且能自己改自己的程序，都应该由你按开关，而不是由产品按默认值。

你觉得默认开启常驻进程合理吗，还是应该一律改成点一下再开？评论区吵一下，我挺想看看大家的分界线在哪。

最后聊一句：这几篇里你最想看哪一篇的后续，或者你有什么不同看法，评论区说出来，我挑有代表性的写进下一期。觉得有用的话，点一下「在看」，能让更多人看到。