用户报告 Codex CLI 0.157.0 默认启动持久化后台守护进程
本条为 AI 依据下方公开信源自动整理生成的摘要，不构成转载，可能存在偏差，请以原文为准。整理者：贝果科技 AI 资讯助手。
本条选题由第三方线索发现；线索方提供的摘要未被采用，本页内容依据下方信源整理。线索来源：AIHOT
全文梳理
AI 摘要依据下方信源原文自动整理，非原文转载默认启动的守护进程
有用户在使用通过 npm install -g @openai/codex 安装的 Codex CLI 0.157.0 时发现，只要打开一个交互式会话，程序就会自动拉起一个常驻后台守护进程，命令为 codex app-server --managed-daemon。该进程运行在独立会话中，没有 TTY，并且在所有 Codex 窗口关闭后依然存活，被重新挂载到 PID 1，直到用户执行 codex app-server daemon stop 或重启系统才会结束。用户认为，对命令行工具而言更符合预期的默认行为是后端随窗口生灭、运行用户自己安装的二进制文件，而不是在后台自行更新。
版本脱钩与自更新循环
该守护进程会把整个平台包复制到 ~/.codex/packages/app-server-daemon/releases/<version>/ 目录下再从副本运行，复制内容与 npm 刚安装的版本逐字节一致，体积约 374 MB，包含 codex、codex-code-mode-host 以及捆绑的 bwrap、zsh、rg。这样一来，后端实际运行的版本就与用户通过包管理器安装的 CLI 版本分离开来。守护进程还会启动一个分离的更新循环，在启动 5 分钟后检查一次更新，之后每小时检查一次，下载新版本并重启后端。用户提到，这种自动更新会在 60 秒排空预算后强制终止进行中的回合，且无法关闭。
环境继承与钩子问题
用户还指出，守护进程会固定住恰好启动它的那个会话的环境变量。例如通过包装脚本按次设置 HTTPS_PROXY 启动 Codex 时，守护进程会保留第一个会话的代理变量，之后无论用什么参数启动新会话，其出站连接都走这个代理。此外，在 --remote 模式下，钩子收到的是守护进程的工作目录而非会话的工作目录；由守护进程生成的钩子也无法识别客户端终端，导致面向终端的钩子失效。用户认为这些问题可能同源。
用户提出的替代方案
该用户建议把 daemon_auto_start 改为可选、默认关闭，或者至少在开启前询问一次。其理由是，共享且自更新的守护进程更适合 Remote Control 或桌面应用场景，在那里默认开启可以接受，也可以在用户显式执行 codex app-server daemon start 或 bootstrap 时启用。如果仍保持默认开启，用户希望至少做到：当最后一个客户端断开时自动退出守护进程；在 CLI 由 npm、brew、pacman 等包管理器安装时不要复制和自更新，而是直接运行已安装的二进制文件。
为什么值得看
涉及 CLI 默认行为、后台自更新与代理环境继承，使用 Codex CLI 的开发者需确认是否受影响。
信源1 家
关键事实
用户报告 Codex CLI 0.157.0 在打开交互式会话时会启动持久化后台守护进程 codex app-server --managed-daemon。[1]
该守护进程无 TTY、独立会话运行，所有 Codex 窗口关闭后仍存活，直到执行停止命令或重启。[1]
守护进程会把约 374 MB 的平台包复制到 ~/.codex/packages/app-server-daemon/releases/<version>/ 并从副本运行。[1]
守护进程启动分离的更新循环，在启动 5 分钟后及此后每小时检查更新并重启后端。[1]
用户请求将 daemon_auto_start 改为默认关闭或至少先询问一次。[1]
相关 · 工具
本页内容由 AI 自动聚合公开信源生成，仅供了解行业动态参考，不构成任何投资或决策建议。如需引用请以原文出处为准。