如果你用 npm 装了 OpenAI 的 Codex CLI，而且版本是 0.157.0 或更新，那你电脑里可能一直跑着一个 Codex 的后台进程，关掉所有 Codex 窗口它也不会退出，还会每小时自己检查更新。这件事这两天在 Hacker News 上讨论得很热，标题就叫“Codex CLI 默认会装一个常驻、自动更新的后台守护进程”。
这篇简单讲一下发生了什么，以及怎么查、怎么关。资料来自 GitHub 上的 issue #48195 及其评论，和 Hacker News 的讨论帖，于 2026 年 10 月 13 日查阅。我没有在自己机器上复现，下面的命令都来自 issue 作者和评论区，执行前请自己判断。
发生了什么
issue 是 2026 年 9 月 26 日（北京时间）提的，作者用的是 Codex CLI 0.157.0、npm 安装、WSL2 环境。他发现从 0.157.0 开始，只要打开一次交互式的 codex，就会发生这几件事：
- 启动一个常驻后台进程（
codex app-server --managed-daemon）。它没有终端，所有 Codex 窗口关掉之后还在跑，直到你手动停掉或者重启电脑。 - 复制一整份程序：大约 374 MB，放到
~/.codex/packages/app-server-daemon/releases/<版本号>/下面，后台进程从这份副本运行。也就是说，后台实际跑的版本，和你用 npm 装的版本脱钩了。 - 启动一个独立的更新进程（
codex app-server daemon pid-update-loop）：启动 5 分钟后检查一次更新，之后每小时一次，会下载新版本并重启后台，可能打断正在进行的任务。 - 沿用第一次启动时的环境变量：比如你每次用不同的代理启动 Codex，后台进程一直用第一次的代理。评论区还有人反馈，在不同目录用不同的环境变量（比如
GH_TOKEN）启动，Agent 拿到的仍是第一个目录的值。
官方 0.157.0 的更新日志只用一句话带过：为符合条件的交互式会话启用自动启动后台服务器。评论区有人指出，官方配置文档里也查不到这个开关。
写这篇时，这个 issue 还是开着的状态，官方没有在 issue 里回复。
怎么检查自己有没有中招
macOS、Linux 或 WSL 里，在终端执行：
ps aux | grep "app-server"
如果看到 codex app-server --managed-daemon 或 pid-update-loop，就说明后台进程在跑。再看看有没有这个目录：
ls ~/.codex/packages/app-server-daemon
Windows 上可以打开任务管理器，在“详细信息”里找 codex 相关的进程。
怎么关掉
issue 作者给出的做法如下，四条命令依次执行：
codex features disable daemon_auto_start
codex app-server daemon stop
pkill -f 'app-server daemon pid-update-loop'
rm -rf ~/.codex/packages/app-server-daemon
分别是：关掉自动启动开关；停掉后台服务；手动杀掉更新进程；删掉那份约 374 MB 的副本。
第三条很关键。作者发现 daemon stop 停掉了后台服务，但更新进程还活着，70 秒后还在，只能手动杀。
另一种关法是改配置文件。评论区一位 Windows 10 用户说，在 config.toml 里加上下面这行就解决了：
daemon_auto_start = false
config.toml 一般在 ~/.codex/ 目录下。按作者的说法，关掉开关后，新开的 Codex 会话就不会再启动后台进程。
我的看法
一个命令行工具，默认在后台常驻、自己更新、还复制一份 370 多 MB 的程序，事先也没明确告诉用户，我觉得这确实不应该是默认行为。issue 作者的诉求也很合理：要么改成默认关闭，要么至少问一次。
评论区有人情绪很大，直接说这“像恶意软件”，这是网友的说法，我觉得没必要上升到这一步，但用 Codex CLI 的人确实值得花一分钟检查一下。另外，评论里有 Windows 用户反馈这个问题会导致 CLI 没法输入，碰到类似情况也可以试试上面的关法。
适合谁看
所有用 npm 等方式装了 Codex CLI 的开发者，尤其是用代理、多项目切换环境变量，或者对后台进程比较敏感的人。
