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

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

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

在最后一个客户端断开连接时退出自动启动的守护进程；
当 CLI 是由包管理器（npm/brew/pacman）安装时，不要复制/自我更新 —— 而是运行已安装的二进制文件（Support externally managed app-server daemon executables #41188、npm update leaves app-server on old version, but daemon update/restart refuse recovery #46468、Codex 0.157.0 no longer starts with the Arch Linux package unless --no-daemon is used #48050）。

附加信息

在关闭它时发现的 Bug：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'   # not stopped by `daemon stop`
rm -rf ~/.codex/packages/app-server-daemon

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

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