摘要：从 Codex CLI 0.157.0 开始，只要打开一次交互式会话，CLI 就会在后台拉起一个常驻的 app-server --managed-daemon：脱离终端、跨窗口存活、把约 374MB 的平台包复制一份到用户目录，并由独立进程每小时自检更新。issue #48195 要求把它改成可选，10 月 12 日仍在更新，当天在 Hacker News 首页拿到 433 分、228 条讨论。
命令行工具的传统契约很简单：进程活到你关掉终端为止。Codex CLI 从 0.157.0 起改掉了这条契约，而且改得很安静——0.157.0 的说明只有一句「为符合条件的交互式会话启用自动后台服务启动」，opt-out 开关甚至没写进配置文档。
结果就是，很多人在不知情的情况下多了一个常驻服务。本文把 issue #48195 里已经核实的行为逐条列出来，说明它对开发环境到底做了什么，以及怎么关掉。
AI Coding 交流群
如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。
发生了什么：一次会话，五种副作用
Issue #48195 由用户 Yihua-Liu-1997 在 2026 年 9 月 25 日提交，标题就是诉求本身：让 daemon_auto_start 变成可选，一个常驻且自更新的后台守护进程不该是默认值。报告基于 Linux/WSL2 上通过 npm install -g @openai/codex 安装的版本，描述的是一条完整的副作用链：
- 打开交互式会话即触发。不需要用户下任何显式命令，进入
codex会话本身就会启动后台服务。 - 拉起 app-server --managed-daemon。新进程在自己的会话里运行、没有 TTY，关掉窗口后被 PID 1 收养，直到执行
codex app-server daemon stop或重启机器才结束。 - 复制约 374MB 平台包。整包被复制到
~/.codex/packages/app-server-daemon/releases/<version>/，里面包含codex、codex-code-mode-host以及随包分发的bwrap、zsh、rg。也就是说，实际跑起来的后端和你用包管理器装的 CLI 是两份东西。 - 独立更新进程自己升级后端。
codex app-server daemon pid-update-loop在启动 5 分钟后检查一次，之后每小时检查；发现新版本会下载并重启后端，而这个重启被指可能打断正在进行的一轮对话（关联 issue #40969 里 60 秒 drain 后 SIGKILL 的行为）。 - 环境变量被首个会话锁定。报告者用一个带
HTTPS_PROXY的启动包装脚本，后续所有会话都会沿用最初那个守护进程的代理变量。
报告者还发现一个附带问题：执行 codex app-server daemon stop 之后，更新循环进程并没有跟着退出，70 秒后仍在运行。
一个具体场景：代理、token 和磁盘
把上面几点放到日常开发里，问题会集中爆发在同一类人身上——需要按项目切换环境的人。
假设你在公司电脑上用代理访问外网，启动脚本按会话注入 HTTPS_PROXY。第一次启动的那份环境被守护进程继承，之后你在另一个网络环境里开会话，走的还是最初的代理配置：命令看起来跑通了，实际流量去了不该去的地方。同一个机制还影响 direnv 用户——有评论提到，从第一次启动目录继承来的 GH_TOKEN 之类的变量会一直粘着，之后的目录切换不再生效。
磁盘是第二个成本。每个版本都在用户目录里留一份约 374MB 的完整包，加上自更新会拉取新版本，长期使用会持续累积，而且这份副本和包管理器管的那份是分开的，卸载 CLI 并不会顺手清掉它。
为什么这改变工作流
这不是「多了一个后台进程」那么简单，而是把 CLI 从「一次调用的工具」变成了「一个长期驻留的服务」，三件事随之改变：
- 生命周期要显式管理。过去退出终端就等于结束；现在需要知道
stop命令，还要确认更新循环是否一起停了。 - 环境不再随会话走。凡是依赖按会话注入环境变量的做法（代理、临时凭据、direnv、容器入口脚本），都可能拿到第一份快照。
- 版本来源不再唯一。包管理器装的版本和守护进程实际运行的版本可能不一致，排查问题时先要确认跑的是哪一个。
社区反应相当激烈，这也是它在 10 月 12 日被顶到 Hacker News 首页（433 分、228 条讨论）的原因。有人直接说「在修好之前这个 CLI 没法用」，也有人把它类比成恶意软件行为并强调这是「装包时没被问过」。这些是用户情绪，不是技术结论，但反映出一个共识：默认值本身是一种承诺，改默认值等于改产品契约。
限制、边界与仍需确认的部分
有几处必须说清楚，避免把它当成安全事件来读：
- 这是设计选择，不是已确认的漏洞。issue 里没有出现提权或远程利用的指控，讨论集中在默认行为、磁盘占用、环境继承和停止不彻底。把它描述成「Codex 是病毒」是社区比喻，不是核查结论。
- 官方尚未实质回应。截至 10 月 12 日，这条 issue 上的官方活动只有机器人打的三个标签（CLI、app-server、enhancement），状态仍是 open，没有 maintainer 给出修复计划。诉求也没有被接受。
- 版本表现不一致。有用户在 0.160.0 上表示没有看到守护进程，也有用户说配置里关掉开关才恢复正常。不同安装方式的差异尚待澄清。
- 文档缺口是真实存在的。官方配置文档记录过
check_for_update_on_startup，但没有记录关闭守护进程的开关，0.157.0 的说明也只有一句话。
想关掉的话，现在可以怎么做
- 在
config.toml中设置daemon_auto_start = false。这是 issue 评论区里被其他用户验证过的关法，但在官方文档补齐之前，建议升级后回头确认一次是否仍生效。 - 已经在跑的会话，执行
codex app-server daemon stop；随后检查更新循环进程是否真的退出，必要时手动结束。 - 清理
~/.codex/packages/app-server-daemon，把已经复制出来的那份平台包删掉。 - 如果你在 CI、容器或共享机器上使用，直接在镜像和启动脚本里就把开关关掉——这类环境最不适合出现跨会话继承环境的常驻进程。
如果你原本就在用 Remote Control 或桌面端这类依赖长驻后端的形态，这个守护进程可能反而是需要的，不必急着关。判断标准很简单：你需要它跨会话活着吗？
信息来源
- openai/codex Issue #48195：CLI: make daemon_auto_start opt-in（2026-09-25 提交，2026-10-12 仍有更新）— https://github.com/openai/codex/issues/48195
- openai/codex Releases（0.157.0 说明）— https://github.com/openai/codex/releases
HiFox ：将 Agent 变成真正的队友
另外，我们也在思考，AI 如何从个人提效走进团队协作。
HiFox 是一个让人和 AI Agent 在同一个工作现场协作的平台：你可以像给同事分派任务一样指派 Agent，在任务看板中跟踪进度、查看结果，让 Agent 成为团队里的队友。
👉 立即体验 Hifox：https://hifox.com
AI Coding 交流群
如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。