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

Codex CLI 0.157.0 默认启动持久化后台守护进程，用户希望其改为可选加入

自 0.157.0 版本起，打开交互式 codex 会话会未经询问即启动一个持久化、自更新的后台守护进程。GitHub 问题 openai/codex#48195 由用户 Yihua-Liu-1997 于 2026 年 9 月 25 日提出，要求将 daemon_auto_start 功能标志改为可选加入（默认 false），或至少在启用前询问一次。该问题在 Hacker News 上获得了 599 分和 292 条评论，主要反应是：通过包管理器安装的 CLI 不应生成长期运行、自更新的服务器进程。

报告者的环境是 Codex CLI 0.157.0，通过 npm install -g @openai/codex 在 Linux（WSL2）上安装。该问题带有 CLI、app-server 和 enhancement 标签。

守护进程做了四件报告者认为令人惊讶的默认行为

根据该问题，仅打开交互式 codex 会话就会触发以下所有行为：

它启动一个持久化的后台守护进程（codex app-server --managed-daemon）。该进程在自己的会话中运行，没有 TTY，并且在所有 Codex 窗口关闭后继续运行，重新父进程为 PID 1，直到执行 codex app-server daemon stop 或重启。
它复制整个平台包——大约 374 MB，包括 codex、codex-code-mode-host 以及捆绑的 bwrap/zsh/rg——到 ~/.codex/packages/app-server-daemon/releases/<version>/。该副本与 npm 刚刚安装的内容字节相同，守护进程从该副本运行。从那时起，后端的版本与用户通过包管理器安装的 CLI 版本脱钩。
它启动一个分离的更新程序（codex app-server daemon pid-update-loop），在启动后五分钟检查更新，然后每小时检查一次，下载新版本并重启后端。该重启可能会终止正在进行的会话，这是另一个在问题 #40969 中跟踪的独立问题。
它固定了启动它的会话的环境。 报告者通过一个包装器启动 Codex，该包装器每次调用设置 HTTPS_PROXY；守护进程保留第一个会话的代理变量，因此其出站连接无论后续会话使用什么环境都通过该代理。

报告者将环境固定行为与问题 #42457（--remote 模式下的钩子接收守护进程的工作目录，而非会话的）和问题 #37537（由 app-server 守护进程生成的钩子无法识别客户端终端）联系起来，认为它们看起来是同一根本原因。

报告者的明确期望：CLI 后端应随窗口生灭

该问题围绕命令行工具的最小惊讶默认值提出了请求：

对于 CLI，最不令人惊讶的默认值是后端随窗口生灭，运行我安装的二进制文件，并且不在后台自行更新。共享的、自更新的守护进程对远程控制/桌面应用有意义，因此在那里启用或用户显式运行 codex app-server daemon start / bootstrap 时启用是可以的。

如果保留默认值，报告者要求两个备选方案：当最后一个客户端断开连接时退出自动启动的守护进程，并且当 CLI 由包管理器（npm、brew、pacman）安装时，不复制或自更新——而是运行已安装的二进制文件。这些请求引用了问题 #41188（支持外部管理的 app-server 守护进程可执行文件）、问题 #46468（npm 更新使 app-server 停留在旧版本，但守护进程更新/重启拒绝恢复）和问题 #48050（Codex 0.157.0 在 Arch Linux 软件包下不再启动，除非使用 --no-daemon）。

`codex app-server daemon stop` 不会停止更新程序

该问题报告了尝试关闭该功能时发现的错误：codex app-server daemon stop 会停止 app-server，但会留下 pid-update-loop 更新程序继续运行。报告者称 70 秒后它仍然存活，不得不手动杀死。

该问题中记录的解决方法如下：

codex features disable daemon_auto_start
codex app-server daemon stop
pkill -f 'app-server daemon pid-update-loop'   # 不被 `daemon stop` 停止
rm -rf ~/.codex/packages/app-server-daemon

关闭标志后，报告者确认新的 TUI 会话不再启动守护进程。

其他平台的确认和配置文件修复

GitHub 问题上的评论者确认了其他系统上的行为，并指出了基于配置的修复方法。

用户 tagorr 报告了 Windows 10 LTSC 上 Codex CLI 0.157.0 的相同问题，并指出在 config.toml 中设置 daemon_auto_start = false 可以解决。tagorr 还提出了两项改进：当守护进程启动被提升权限阻止时自动回退到本地模式，而不是要求 --no-daemon；使守护进程自动启动成为可选加入而非默认。问题作者回复说两者都可行。

用户 felipeelopes 写道，Windows 上由于此错误，Codex CLI 无法使用。用户 megahall（似乎以维护者身份回复）写道：

感谢报告，我自己也遇到了……在小的版本号提升时，不应该突然创建神秘服务器和进程而不提前通知人……

用户 kr8vka0z 写道，在修复之前 CLI 无法使用。用户 skhaz 添加了“+1 禁用此功能。”用户 laurynas-karvelis 更直接：“基本上——是恶意软件的特征。说实话，我不认为这是偶然发生的。”

来源论证：已安装的 CLI 身份不等于守护进程执行身份

用户 aetherxeg-source 的评论将问题框定为来源边界问题，指出 已安装的 CLI 身份 != 守护进程执行身份。论证是，一旦 CLI 将自己复制到托管发布目录，并且后台更新程序可以替换该副本，则服务后续会话的进程不再一定是用户显式安装或调用的工件。

该评论提议守护进程为每个客户端连接公开一个小的执行收据，至少包含 client_cli_version + daemon_binary_digest + daemon_generation + updater_state + inherited_environment_generation，以便客户端可以区分四种状态：相同的已安装工件和相同的守护进程代；相同的 CLI 但不同的守护进程代；守护进程二进制独立于包管理器状态改变；以及守护进程从早期会话继承了环境。

下游打包者开始禁用守护进程自动启动

多个第三方仓库添加了引用该问题的提交，表明打包者将默认行为视为需要覆盖的内容。这些包括 nixvital/ml-pkgs 中标题为“codex: disable daemon auto-start by default”的提交（2026 年 9 月 28 日）、更新 Codex 到 0.160.1 并带有 nix-user-chroot 沙盒补丁的 dotfiles 提交（2026 年 10 月 7 日），以及从官方发布二进制打包 Codex CLI 的 NixOS 提交（2026 年 10 月 10 日）。

在 Hacker News 上，争论分为“这像恶意软件”和“浏览器也这样做”

Hacker News 线程出现了强烈批评和对自动更新的辩护。

批评集中在信任、磁盘使用和回归上。 用户 icantevenhold 报告旧版本填满了磁盘：“我调查了一下，它总共占了我系统大约 12 GB；这对我来说似乎疯狂，它只是一个工具？人们抱怨 Claude code 做得多么糟糕，但 Codex 似乎每个指标都更差。”用户 dllu 报告守护进程的自动更新破坏了文件权限：“自动更新时，它会随机破坏权限，并因 .git 变为只读而阻止目标。”用户 ranger_danger 简单写道：“在某些圈子里，这被称为后门。”用户 soletta 写道：“删除 codex 并退订。谢谢你，楼主，突出显示了这一重要的 PSA。”

辩护是自更新现在是标准。 用户 dingaling911 写道：“这些东西发展很快，应该自动更新。这现在有点标准了。浏览器这样做。没有理由工具不这样做。”用户 piker 说他们构建了一个法律 IDE，认为意图不一定是敌对的：“我们考虑了各种更新方法，在我们的法律 IDE 中，安全、稳定性等是至关重要的，让有缺陷的应用程序在外流传是对用户不友好的……我们考虑了守护进程方案，但最终在每次启动时进行硬更新检查。”用户 infinite_spin 指出背景很重要：“我期望在安装/运行客户端时出现这种事情，但我能理解为什么通过 NPM 安装的 CLI 这样做会令人震惊。”

据一位评论者称，Claude Code 使用类似的运营模式

用户 timdorr 指出这种模式并非 Codex 独有，写道它是“与 Claude Code 相同的运营模式”，并引用了 ls ~/.local/share/claude/versions/ 和 ps auxww | grep "claude bg"，这些显示了先前版本的 Claude Code 二进制文件和几个正在运行的后台任务，而前台没有 Claude Code。

Hacker News 线程中记录的解决方法

多位评论者描述了禁用守护进程的方法。

用户 whimblepop（提交了该故事）指出没有记录设置来禁用该功能，但它目前位于一个功能标志后面，可以在 ~/.codex/config.toml 中翻转：

[features]
daemon_auto_start = false

whimblepop 还描述了一种更激进的方法：守护进程在启动时将 pid 文件和锁文件写入 ~/.codex，可以删除这些文件并用指向 /dev/null 的符号链接替换，然后用 chattr +i 标记为不可写，这样如果功能标志被移除，后台守护进程将在启动时崩溃。

用户 grimgrin 发布了一个冗余的双保险配置，结合了配置文件和 shell 函数：

codex() { command codex --no-daemon "${@:-.}" }

用户 gruntled-worker 补充说，可执行文件可以简单地复制并用 --no-daemon 运行，并且最近的终端 UI 更改可以通过 CODEX_TUI_DISABLE_KEYBOARD_ENHANCEMENT=1 和 /tui 命令禁用。

一位评论者认为，环境继承问题是最敌视用户的部分

用户 yearolinuxdsktp 特别指出了环境行为，而不是守护进程本身：

我认为这个默认更改中最敌视用户的方面是静默破坏“命令在其启动的 shell 环境中运行”的约定/期望。例如，一个启动钩子断言有效环境会失败，因为它在应用服务器的环境中运行。它还静默地停止使用守护进程，如果你传入几乎任何 -c 参数，例如模型上下文大小。

平台特定破坏：Windows 控制台窗口和提升权限

用户 ilitirit 报告在 Windows 上该工具“每次执行（？）命令时还会启动一个新的控制台窗口”，并建议使用 --no-daemon 禁用它，补充说 CLI“两周前完全可用”。GitHub 问题上来自 tagorr 和 felipeelopes 的 Windows 确认指向同一平台受到不成比例的影响，tagorr 特别要求当守护进程启动被提升权限阻止时自动回退到本地模式。

对 Codex 和 AI 工具质量的更广泛抱怨

几位评论者利用该线程批评 AI 编码工具的整体状态，而不仅仅是守护进程。

用户 Alifatisk 描述 Codex VS Code 扩展“脆弱得离谱”，说它完全坏了大约一周才部分修复，多个问题跟踪相同的问题，社区已经开始自己修补扩展。Alifatisk 写道他们关闭了该扩展的自动更新——这是他们唯一需要这样做的扩展——并总结道：“我现在经历了‘快速行动并打破东西’的后果。我意识到软件质量对我有多重要。”

用户 esjeon 写道：“我认为 Codex CLI（和 Claude Code）的质量是 LLM 驱动开发现状的诚实反映。未来看起来并不乐观。”用户 compiler-guy 认为，用户体验只有在长期一致地应用专注品味时才能改善，“如果没人花时间，用户体验将继续糟糕。而且似乎没有人这样做。”用户 Sha1rholder 质疑是否有人类测试，称 ChatGPT、Codex Desktop 和 Android 应用的前端质量“简直糟糕透顶”。

打包的反驳：发行版正是为了防止这种情况

用户 thebeardisred 认为该事件验证了操作系统发行模式：“你会有打包软件并测试的人，做出通常合理的默认设置，通常会阻止这种恶作剧发生。”用户 AndreasBackx 提出了关于重新发明的相关观点，指出 Codex 安装脚本自行管理安装，而不是使用现有的包管理器：“我们已经通过包管理器解决了软件更新问题。我们是否需要守护进程不断检查更新，并且需要 shell 脚本绕过包管理器？”

用户 clutter55561 推荐隔离而不是配置：“永远不要将这些安装到你的主机中。锁定的 Docker 容器是最低限度。固定你的版本，并在不检查变更日志的情况下永远不更新。”用户 umutsevdi 报告在基准测试时发现守护进程，并切换到在这些工具周围使用 bwrap 以获得准确的测量结果。

用户迁移到的替代方案

几位评论者提到了更轻量级的工具。用户 reacharavindh 描述通过 hax 使用 GPT 模型，“一个带有最少工具的基本工具”，大多数任务依赖 bash，并通过系统提示中的一行按需添加 CLI 工具。用户 sva_ 推荐 Pi Coding Agent，认为“它更轻量级，而且根据我的经验，比任何专有工具都好得多。”用户 silverbluep 说他们放弃了 Codex，因为它“混合了状态和配置数据”，这阻止了 nix-darwin 环境中的声明式管理，现在仅通过 opencode 使用 Codex。用户 pkulak 指出了缓解因素：“OpenAI 至少允许你使用任何你喜欢的工具。有一个糟糕的一方可选方案是坏的，但逃生舱给它一个下限。”

该问题要求的内容，一句话总结

将 Codex CLI 的 daemon_auto_start 默认值改为 false，或在启用前提示一次；如果保留默认值，则在最后一个客户端断开连接时退出守护进程，并且当 CLI 由包管理器安装时停止复制或自更新。截至问题最后活动日期（2026 年 10 月 12 日），该问题仍处于开放状态，没有分配人、里程碑或关联的拉取请求。