Codex CLI 默认拉起常驻自更新守护进程：issue 开 18 天无回应，OpenAI 工程师认下更新子系统疏漏
Codex CLI 自 0.157.0 起打开会话即拉起常驻自更新守护进程，有用户报旧版本堆积约 12GB；OpenAI 工程师称更新子系统是疏漏，会去修。
Codex CLI 是 OpenAI 开源的终端编码智能体。2026 年 9 月 25 日，用户 Yihua-Liu-1997 在 openai/codex 仓库提交 issue #48195：从 0.157.0 起，只要打开一个交互会话，CLI 就在后台静默拉起守护进程 codex app-server --managed-daemon，无 TTY、脱离终端存活、重挂到 PID 1，直到执行 codex app-server daemon stop 或重启才退出。这份 issue 在 18 天里没有等到 OpenAI 维护者的回应；10 月 12 日经 Hacker News 用户 whimblepop 提交后发酵，截至 10 月 13 日已有 370 分、约 200 条评论，OpenAI 工程师 Charlie Marsh 当天在讨论串里回应称更新子系统「像是个疏漏」，他会去修。
要点
- 0.157.0 起，Codex CLI 打开交互会话即启动常驻守护进程（重挂 PID 1），并把约 374MB 平台包复制进
~/.codex/packages/app-server-daemon/releases/<版本>/，数字出自 issue 作者的 Linux/WSL2 环境。 - 守护进程附带独立更新器
pid-update-loop：启动 5 分钟后首查、之后每小时查更新并重启后端；作者实测daemon stop杀不掉它，70 秒后仍存活。有用户报告旧版本累计占用约 12GB。 - 关闭开关是
codex features disable daemon_auto_start，截至 10 月 13 日未写入官方文档；Charlie Marsh 只认了更新子系统的疏漏，未回应把守护进程改 opt-in 的核心诉求。
背景
Codex CLI 经 npm、brew 等包管理器分发，issue 作者用 npm install -g @openai/codex 装的 0.157.0。对后台进程的抱怨此前已有线索：作者把 #42457、#37537（守护进程沿用首个会话的工作目录与终端）和 #40969（自动更新重启后端可能打断进行中的任务）列为同一根因。openai/codex 在 10 月 9 日发布了 0.162.1，而这份要求改默认值的 issue 至今 open。终端编码智能体大多跟随终端窗口生灭，走极简路线的 Pi 框架把进程生命周期交还给用户；Codex 生态近期的动态集中在模型层，比如 GPT-6.1 Sol 默认上下文升至 500k，把后台运行做成默认行为还是第一次。
事实部分
issue 正文列出的四项行为、关闭方法与一处连带 bug，均在作者环境（Linux/WSL2，npm 安装）实测：
| 行为 | 细节 | 来源 |
|---|---|---|
| 常驻守护进程 | codex app-server --managed-daemon，无 TTY，重挂 PID 1 | issue #48195，2026-09-25 |
| 复制平台包 | 约 374MB（codex、codex-code-mode-host、内置 bwrap/zsh/rg），存入 ~/.codex/packages/app-server-daemon/releases/<版本>/ | 同上，用户报告 |
| 自更新 | pid-update-loop 启动 5 分钟后首查，之后每小时查，下载新版本并重启后端 | 同上 |
| 环境钉住 | 守护进程保留首个会话的 HTTPS_PROXY，后续会话出站仍走首个会话的代理 | 同上 |
| 关闭 | codex features disable daemon_auto_start，或 config.toml 里 [features] daemon_auto_start = false；HN 用户称该开关未写入文档 | issue 与 HN |
374MB 是单台机器的实测值，不同平台会有出入。daemon_auto_start 在仓库代码中出现于 9 处（含 config.schema.json），10 月 13 日检索时没有一处位于 docs/ 目录。
各方说法
Hacker News 讨论串把影响面铺开。icantevenhold 排查发现旧版本累计占约 12GB（「它只是个 harness？」）；rfgplk 确认 .codex/packages/standalone/releases 保留所有旧版本，单个二进制约 300MB；dllu 说自动更新曾「随机把权限改坏，让 .git 变成只读」，长任务因此中断；ilitirit 说 Windows 上每执行一条命令就弹出一个新控制台窗口。ranger_danger 的说法最直接：「In some circles this is called a backdoor.」
issue 下的用户报告同样具体。tagorr 在 Windows 10 LTSC 上确认 0.157.0 存在同样行为，把 daemon_auto_start 设为 false 后消失；felipeelopes 称 CLI 在 Windows 上因此「不可用」，这是他一个人的说法，但用户 zdd 报告的完全无法输入与之呼应。
timdorr 指出 Claude Code 的运行模型相同：~/.local/share/claude/versions/ 里堆着旧版本二进制，claude bg 后台任务在前台副本关闭后仍在跑。这条评论下有人提到 Nix 包会把这套逻辑补丁掉，也有人贴出 Claude Code 的 issue #14980，摘要只有一句「They don’t care」。
官方一侧，Charlie Marsh（GitHub 简历自述在 OpenAI 参与 Astral 团队，Ruff、uv 的作者）10 月 12 日 19:22 UTC 回应 12GB 报告：“I haven’t worked with the update subsystem before but that seems like an oversight to me. I’m gonna fix it.” 他没有回应把守护进程改 opt-in 的诉求。下游已经动手：Nix 包仓库 nixvital/ml-pkgs 给 codex 打了 no-daemon_auto_start.patch，补丁注释直接引用 issue #48195。主流媒体截至 10 月 13 日没有跟进，英文、中文各搜一轮，讨论仍集中在 GitHub 与 HN；HN 内部对自动更新本身也有分歧，有人拿浏览器类比支持自动更新，swatcoder 认为专业工具不该默认自动更新。
怎么关
issue 作者给出的完整步骤如下，daemon stop 停不掉更新器，需要手动补一刀：
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
或者写进 ~/.codex/config.toml：
[features]
daemon_auto_start = false
作者实测关掉后，新开的 TUI 会话不再拉起守护进程。判断自己是否中招，可以跑 ps aux | grep managed-daemon，或者看看 ~/.codex/packages/app-server-daemon/releases/ 下堆了几层版本。
编辑判断
对每天开着 Codex 干活的人，这件事的实际影响有三层：包管理器装进来的版本与实际运行的后端可能就此解耦，你跑的未必是你装的；走 HTTPS_PROXY 包装脚本的人，出站流量会被钉在首个会话的代理上；自动更新随时重启后端，长任务有被打断的风险。所有磁盘数字都出自用户报告，374MB 来自作者的一台 WSL2 机器，别把它当成普适值。修复的边界也还没定：Charlie Marsh 只认了更新子系统的疏漏，守护进程是否改 opt-in、开关会不会写进文档，都挂在仍然 open 的 issue 里。官方表态之前，能做的是手动关闭，然后盯住 #48195。