AI 范式雷达：《当你的笔记本上住进别人家的守护进程》
内容提要
Codex CLI 自 0.157.0 起默认安装常驻守护进程，将 374MB 包复制到家目录并每小时自更新，关闭窗口后仍运行，引发 #48195 要求改为选择性加入。争议核心是版本、进程、配置三样主权被默认没收，且关闭路径不完整。解法是改为 opt-in、补充文档说明并彻底停止。
延伸解读
三样主权被默认没收
Codex CLI 从 0.157.0 起默认安装常驻守护进程，将 374MB 包复制到家目录并每小时自更新，关闭窗口后仍运行。这导致版本、进程、配置三样主权被默认没收：npm update 升的是 CLI 壳，后端来自 ~/.codex/packages 里更新器挑的那份；会话结束不再等于进程结束；守护进程钉住启动它的会话环境变量。争议核心是默认值加可见性加退出路径完整性，而非自动更新本身。
关闭路径不完整
实测显示，daemon stop 停了 app-server，但 pid-update-loop 仍会存活约 70 秒，需手动 kill 才能彻底停止。官方 config 参考页对 daemon_auto_start 零条目，唯一可见的关闭方式是 config.toml 的 feature flag。这种关闭不干净的情况，加上发布说明仅一句话提及，使得用户难以完全掌控进程，加剧了主权被侵犯的感受。
生态同构与双通道分叉
类似形态并非孤例：Claude Code 在 ~/.local/share/claude/versions/ 驻留多版本且有后台进程。双通道分叉是安静症状：npm update 后 CLI 壳升到新版，app-server 停在旧版，包管理器认为装了 A，更新器认为跑了 B。这显示 Agent 工具正从会话级应用滑向常驻基础设施，配套消费软件式更新模型，但未经用户同意。
企业合规缺口与自查
企业走内网 npm 镜像时，镜像管得住安装瞬间，却管不住 ~/.codex/packages 里的小时级自更新，合规链在复制包这步断掉。建议将 ~/.codex/packages 与 ~/.codex/app-server-daemon 纳入终端合规扫描。用户可自查：ps aux 与 du -sh 观测进程和目录；关闭则依次执行 codex features disable daemon_auto_start、daemon stop、pkill -f pid-update-loop 并删复制包目录。
Q&A
Codex CLI 从哪个版本开始默认安装常驻守护进程？
从 0.157.0 版开始，打开一次交互式 codex 会话后，它会默认安装常驻守护进程。
Codex CLI 守护进程默认启动后，机器上会多出哪些东西？
会多出四个东西：一个常驻守护进程（codex app-server --managed-daemon）、一份 374 MB 的平台包副本（复制到 ~/.codex/packages/.../releases/<version>/）、一个分离式更新器（pid-update-loop，每小时自更新）、一份被固定住的环境（钉住启动它的会话的环境变量）。
为什么 Codex CLI 守护进程事件引发争议？
争议核心是版本、进程、配置三样主权被默认没收：版本主权上，npm update 升的是 CLI 壳，后端来自 ~/.codex/packages 里更新器挑的那份；进程主权上，会话结束不再等于进程结束，唯一自动退出条件是重启；配置主权上，它带启动它的那个会话的环境活到明天。此外关闭路径不完整，daemon stop 后更新器仍残留。
如何彻底关闭 Codex CLI 的守护进程和自更新？
依次执行：codex features disable daemon_auto_start、daemon stop、pkill -f pid-update-loop，并删除复制包目录；或在 config.toml 的 [features] 段写 daemon_auto_start = false。stop 后需确认更新器残留。
企业环境如何应对 Codex CLI 守护进程的合规缺口？
走内网 npm 镜像的话，把 ~/.codex/packages 与 ~/.codex/app-server-daemon 纳入终端合规扫描（完整性基线或 MDM 策略），因为镜像层管不到这里。
Codex CLI 守护进程事件反映了什么范式转变？
标志着 Agent 工具的分发范式从「会话级应用」切换为「常驻基础设施」，配套消费软件式的更新模型——默认开启、静默安装、小时级自更新、退出包管理器管辖。
未来一到两个雷达周期有哪些观察点？
五个观察点：厂商让步信号（#48195 是否翻转默认 opt-in、daemon_auto_start 是否进官方文档）、同构蔓延信号（Claude Code、Cursor 等是否被实测出常驻、小时级自更新、复制包三件套）、第一次事故实锤（是否出现自动更新引入回归的有名有姓事件）、发行版与企业反制（Arch/AUR 等是否系统性加 --no-daemon 补丁；MDM 是否出现 daemon 禁用模板）、治理同构信号（是否有人把 agent daemon 纳入工作负载治理工具链）。
