你使用的 Codex 版本是什么？CLI — 0.157.0，通过 npm install -g @openai/codex 安装，Linux (WSL2) 你希望看到什么功能？请让 daemon_auto_start 成为用户选择（默认为 false）对于 CLI，或者至少在开启之前询问一次。自 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 在 60 秒耗尽预算后强制结束活跃回合，并且无法禁用 #40969）。锁定启动它的任何会话的环境。我通过一个包装器启动 Codex，该包装器在每次调用时设置 HTTPS_PROXY；守护进程保持第一个会话的代理变量，其出站连接通过该代理，无论后续会话如何启动。以 --remote 模式接口的 Hook 接收到守护进程的当前工作目录，而不是会话的 #42457，且由 app-server 守护进程生成的 Hook 无法识别客户端终端，破坏了针对终端的 Hook #37537（守护进程的当前工作目录 / 终端而不是会话的）看起来是同样的根本原因。对于 CLI，最惊讶的默认设置是后端与窗口一起生存和死亡，运行我安装的二进制文件，并且不在后台自我更新。共享的自我更新守护进程对于远程控制/桌面应用程序是合乎逻辑的，因此在这些地方启用它，或者当用户显式运行 codex app-server daemon start / bootstrap 时也可以。如果保持默认开启，请至少：当最后一个客户端断开连接时，退出自动启动的守护进程；在通过包管理器（npm/brew/pacman）安装 CLI 时不复制/自我更新 — 而是运行已安装的二进制文件（支持外部管理的 app-server 守护进程可执行文件 #41188，npm update 留下 app-server 在旧版本上，但守护进程更新/重启拒绝恢复 #46468，Codex 0.157.0 不再在 Arch Linux 包下启动，除非使用 --no-daemon #48050）。附加信息 关闭它时发现的错误：codex app-server daemon stop 停止应用服务器但留下 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 会话不再生成守护进程。相关：#40969，#41188，#46468，#48050，#42457，#37537