用户报告 Codex CLI 0.157.0 默认启动持久化自更新后台守护进程

你使用的是哪个版本的 Codex？

CLI — 0.157.0，通过 npm install -g @openai/codex 安装，Linux（WSL2）

你希望看到什么功能？

请让 daemon_auto_start 在 CLI 中选择启用（默认 false ） ，或者至少在开启前询问一次。

自 0.157.0 起，只要打开一个交互式 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 ），它在启动 5 分钟后检查更新，之后每小时检查一次，下载新版本并重启后端（这可能会终止正在进行的回合，见 app-server daemon: auto-update force-kills active turns after a 60s drain budget, and cannot be disabled &nbsp;#40969 ）。

· 会固定住恰好启动它的那个会话的环境。 我通过一个包装器启动 Codex，每次调用都会设置 HTTPS_PROXY ；守护进程会保留第一个会话的代理变量，其出站连接都会经过那个代理，无论后续会话是用什么启动的。 Hooks in --remote mode receive the daemon's cwd, not the session's &nbsp;#42457 和 Hooks spawned by the app-server daemon cannot identify the client terminal, breaking terminal-targeting hooks &nbsp;#37537 （守护进程的 cwd / 终端而不是会话的）看起来是同一个根本原因。

对于 CLI 来说，最不令人意外的默认行为是：后端随窗口一起生灭，运行我安装的二进制文件，并且不会在后台自我更新。共享的、可自我更新的守护进程对 Remote Control / 桌面应用来说是有意义的，所以在那里启用它没问题，或者在用户显式运行 codex app-server daemon start / bootstrap 时启用也可以。

如果它仍默认开启，请至少：

· 在最后一个客户端断开连接时退出自动启动的守护进程；

· 当 CLI 是由包管理器（npm/brew/pacman）安装时，不要复制/自我更新 —— 而是运行已安装的二进制文件（ Support externally managed app-server daemon executables &nbsp;#41188 、 npm update leaves app-server on old version, but daemon update/restart refuse recovery &nbsp;#46468 、 Codex 0.157.0 no longer starts with the Arch Linux package unless --no-daemon is used &nbsp;#48050 ）。

附加信息

在关闭它时发现的 bug： codex app-server daemon stop 会停止 app-server，但会让 pid-update-loop 更新器继续运行（70 秒后仍然存活，不得不手动杀掉它）。

我正在使用的变通方法：

关闭该标志后，新的 TUI 会话不再生成守护进程。

相关： #40969 、 #41188 、 #46468 、 #48050 、 #42457 、 #37537