Codex CLI 默认安装一个持久的、自更新的后台守护进程

原文 ↗ Hacker News 讨论 ↗

OpenAI 的 Codex CLI 现在默认安装一个持久的、自更新的后台守护进程，这引发了人们对用户控制、隐藏资源占用以及旧版本占用大量磁盘空间的担忧。评论者认为，专业工具不应自动更新，也不应在用户明确控制之外运行长生命周期进程，尤其是在这些工具本身已经有漏洞、且容易破坏工作流程的情况下。许多人将这种行为与传统操作系统包管理器以及更轻量的第三方“harness”形成对比，并把 Codex 及类似 AI 工具（如 Claude Code）视为仓促的、由 LLM 驱动的软件开发的缩影：它优先追求快速功能增长，而不是稳定性、透明度和平台惯例。

自动更新的守护进程行为

  • Codex CLI 现在会安装一个持久的后台守护进程，该守护进程会自动更新并保留旧版本。
  • 许多人认为这对用户不友好：它会在 CLI 退出后继续存在，可能让用户感到意外，而且很难控制。
  • 也有人认为快速演进的 AI 工具“需要”自动更新，把它类比为浏览器和桌面应用。
  • 几位发帖者坚持认为，这最多只能作为明确的可选项接受，而不应成为默认设置，尤其是对于专业工具。

磁盘空间、性能与杂乱

  • 用户报告称有多个大型二进制文件以及大量旧版本在不断堆积（从几 GB 到几十 GB 不等）。
  • 对其他 harness（Cursor、Claude Code、VS Code 配置）也有类似抱怨，说它们把日志、临时目录和缓存到处留在系统里。
  • 一些人会通过脚本、快照，甚至用 LLM 来识别“垃圾”文件，定期清理。

可靠性与软件质量

  • Codex CLI、Codex VS Code 扩展、Claude Code 以及其他 harness 被描述为脆弱、更新后经常回归，并破坏基本 UX（滚动、复制/粘贴、子代理、登录流程）。
  • 许多人将这归因于“vibe coding”和大量由 LLM 生成的代码：功能容易堆砌、架构糟糕、几乎没有人工测试。
  • 也有人指出，出问题的旗舰级 harness 其实诚实反映了当前 LLM 驱动开发的现状。

控制、安全与沙箱化

  • 有人担心，持久守护进程和自动更新会削弱用户控制，并且看起来像后门。
  • 一些用户把 harness 隔离在容器、VM、microVM 或 bubblewrap 之类的工具中，或者干脆不把它们安装到主机上。
  • 有些人报告说，代理比以前更激进地读取凭据或运行 shell 命令，而且没有清晰警告。

配置、标志与规避办法

  • 有人分享隐藏/未记录的特性标志（daemon_auto_start = false）以及 --no-daemon，作为禁用守护进程的方法。
  • 也有人担心默认值和标志会随着时间变化，迫使人们持续保持警惕。
  • 包管理器和 Nix 用户更偏好打过补丁的构建版本，以去掉自更新行为。

替代方案与偏好

  • 轻量级、“极简”的 harness（例如 hax、Pi、其他项目）经常因尊重 XDG、避免守护进程、并表现得像普通 CLI 工具而受到称赞。
  • 一些用户改回手动使用 API 或网页界面，或者因为这些变化而取消订阅/删除 Codex。