Codex CLI installs a persistent, self-updating background daemon by default

CLI：将 `daemon_auto_start` 设为需用户主动启用 — 持久运行、自动更新的后台守护进程不应作为默认行为 · Issue #48195 · openai/codex · GitHub

仓库导航

$

CLI：将 daemon_auto_start 设为需用户主动启用 — 持久运行、自动更新的后台守护进程不应作为默认行为 #48195

$!

新建问题

/$

复制链接

打开

CLI：将

daemon_auto_start

设为需用户主动启用 — 持久运行、自动更新的后台守护进程不应作为默认行为

#48195

标签

CLI

与 Codex CLI 相关的问题

app-server

涉及应用服务器协议或接口的问题

enhancement

新功能或需求

描述

Yihua-Liu-1997

于 2026 年 9 月 25 日创建

问题正文操作

您使用的是哪种 Codex 版本？

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

您希望看到什么功能？

请将 CLI 的 daemon_auto_start 设为需用户主动启用（默认值为 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：自动更新会在 60 秒排水预算后强制终止正在进行的操作，且无法禁用 #40969）。

• 会固定启动该守护进程的会话环境。我通过一个设置 HTTPS_PROXY 的包装器启动 Codex；守护进程会保留第一个会话的代理变量，所有出站连接都会通过该代理，无论之后启动的会话如何设置。--remote 模式下的钩子会接收守护进程的当前工作目录，而非会话的 #42457；由 app-server 守护进程启动的钩子无法识别客户端终端，导致终端定向钩子失效 #37537（守护进程的当前工作目录/终端而非会话的）看起来像是相同的根本原因。

对于 CLI 工具，最不令人意外的默认行为是后端应与窗口同时启动和关闭，运行我安装的二进制文件，并且不会在后台自动更新。共享的、自动更新的守护进程适用于远程控制/桌面应用，因此在这些场景中启用它是合理的，或者当用户明确执行 codex app-server daemon start / bootstrap 时启用。

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

• 当最后一个客户端断开连接时，终止自动启动的守护进程；

• 当 CLI 通过包管理器（npm/brew/pacman）安装时，不要复制/自动更新 — 而是运行已安装的二进制文件（支持外部管理的 app-server 守护进程可执行文件 #41188，npm update 会将 app-server 留在旧版本，但守护进程更新/重启拒绝恢复 #46468，Codex 0.157.0 除非使用 --no-daemon 参数，否则不会与 Arch Linux 包一起启动 #48050）。

额外信息

/think

Bug 在关闭时被发现：codex app-server 守护进程停止命令会停止 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 会话将不再启动守护进程。

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

当前无法进行反应

活动

• github-actions 添加了增强功能 新功能或请求 新功能或请求 CLI 与 Codex CLI 相关的问题 与 Codex CLI 相关的问题 app-server 涉及应用服务器协议或接口的问题 涉及应用服务器协议或接口的问题 于 2026 年 9 月 25 日

• megahall 于 2026 年 9 月 25 日评论 megahall 于 2026 年 9 月 25 日 更多操作 @Yihua-Liu-1997 感谢你报告这个问题，我自己也遇到了... 版本号小幅提升时不应突然创建神秘服务器和进程而不提前通知用户... 👍 点赞 14 点赞者包括 tagor, Flaviu Tamas, Felipe Lopes, Josh Triplett, BigBoyDevBox, Kamil Mielnik, Mikhail, Ayanami Kaine, Mike Elliott, Alexander Williamson 和 4 位更多

• kr8vka0z 于 2026 年 9 月 25 日评论 kr8vka0z 于 2026 年 9 月 25 日 更多操作 同意。在修复此问题之前，CLI 完全无法使用。 👍 点赞 16 点赞者包括 tagor, Steven Dale, Felipe Lopes, krrr, Shaun Pedicini, Christian Hahn, BigBoyDevBox, Mikhail, Ayanami Kaine, Mike Elliott 和 6 位更多

• tagorr 于 2026 年 9 月 25 日评论 tagorr 于 2026 年 9 月 25 日 更多操作 我可以在 Windows 10 LTSC 上使用 Codex CLI 0.157.0 确认此问题。在 config.toml 中设置 daemon_auto_start = false 可解决此问题。两个改进建议会有帮助：当守护进程启动因权限提升被阻止时，自动回退到本地模式，而不是需要 --no-daemon 参数。将守护进程自动启动设为可选而非默认。这可以保留安全限制而不干扰正常的 CLI 工作流程。 👍 点赞 1 点赞者包括 BigBoyDevBox

• Yihua-Liu-1997 于 2026 年 9 月 26 日评论 Yihua-Liu-1997 于 2026 年 9 月 26 日 作者 更多操作 @tagorr 确实如此——1 和 2 都有效~ ❤️ 点赞 1 点赞者包括 tagor

• breakds 于 2026 年 9 月 28 日添加了一个引用此问题的提交 codex: 默认禁用守护进程自动启动 ... b51c036

• felipeelopes 于 2026 年 9 月 29 日评论 felipeelopes 于 2026 年 9 月 29 日 更多操作 由于此错误，Windows 上的 Codex CLI 完全无法使用。

• zdd 于 2026 年 9 月 30 日评论 zdd 于 2026 年 9 月 30 日 更多操作 这太糟糕了。我完全无法在 CLI 上输入任何内容。你们应尽快修复此问题并给我们 100 个银行重置！

• aetherxeg-source 于 2026 年 10 月 3 日评论 aetherxeg-source 于 2026 年 10 月 3 日 – 使用 ChatGPT Codex Connector 更多操作 此请求背后有一个有用的溯源边界：已安装的 CLI 身份 != 守护进程执行身份 一旦 CLI 将自身复制到受管理的发布目录中，后台更新器可以替换该副本，那么处理后续请求的进程可能不再是用户明确安装或调用的工件。我会让守护进程为每个客户端连接暴露一个小的执行收据，至少包含以下内容：client_cli_version + daemon_binary_digest + daemon_generation + updater_state + inherited_environment_generation 然后客户端可以区分：相同安装的工件，相同守护进程生成版本；相同 CLI 但不同守护进程生成版本；守护进程二进制文件独立于包管理器状态发生变更；守护进程继承了早期会话的环境。一个强回归测试应从环境 A 启动守护进程，从环境 B 连接，更新已安装的 CLI，并验证客户端能准确看到哪个守护进程生成版本/二进制文件/环境对当前操作具有权威性，而不是根据前台 CLI 版本推断。相关的运行时行为完整性工作：https://github.com/AETHERXGLOBAL/execsurface

• difro 在 2026 年 10 月 7 日提交了引用此问题的提交 更新 codex 至 0.160.1 并添加针对 nix-user-chroot 的沙箱补丁 ... cff8b11

• danielscoffee 在 2026 年 10 月 10 日提交了引用此问题的提交 feat(codex): 从官方发布二进制文件打包 Codex CLI ... 4f00eb3

• xizhou0606 在 2026 年 10 月 12 日提交了引用此问题的提交 添加 10 月 12 日技术新闻（增量扫描窗口 18:00-19:00 UTC 10 月 12 日 … ... 0c9fad3

• laurynas-karvelis 于 2026 年 10 月 12 日评论 laurynas-karvelis 于 2026 年 10 月 12 日 最后由 laurynas-karvelis 编辑 更多操作 基本上 - 恶意软件的特征。老实说，我认为这甚至不是意外造成的 👍 点赞 11 由 tagor, Ymir, Abhiram S Sajeev, r3nor, Mike Elliott, Hemanth Devarapalli, Aaron Wade, Artur Sinila, Guido, Yaadata (Yadi) 和 1 位更多人 ❤️ 点赞 1 由 tagor

• skhaz 于 2026 年 10 月 12 日评论 skhaz 于 2026 年 10 月 12 日 更多操作 支持禁用此功能

• tagorr 于 2026 年 10 月 12 日评论 tagorr 于 2026 年 10 月 12 日 更多操作 基本上 - 恶意软件的特征。老实说，我认为这甚至不是意外造成的 说实话，这正是它给人的感觉。

• st396gt 于 2026 年 10 月 12 日评论 st396gt 于 2026 年 10 月 12 日 更多操作 文档中提到需要对整个主机文件系统拥有完全的读写权限，这就是我为什么在加固的树莓派上运行 codex-cli 并通过 SSH 连接到它的原因。我看不到有守护进程在运行，使用的是上周的 v0.160.0 版本。

• Logarithmus 于 2026 年 10 月 12 日评论 Logarithmus 于 2026 年 10 月 12 日 更多操作 那么 codex 现在是病毒了？如果他们用它来创建一个由这些住宅 IP 组成的僵尸网络用于网页抓取，我一点也不意外 👍 点赞 2 由 Rodrigo Delduca 和 Wilson

• mateolafalce 于 2026 年 10 月 12 日评论 mateolafalce 于 2026 年 10 月 12 日 更多操作 同意，这是个好决定

注册免费

加入 GitHub 上的讨论。

已有账户？

登录评论

元数据

负责人

无人分配

标签

类型

无类型

项目

无项目

里程碑

无里程碑

关系

尚无

开发

无分支或拉取请求

问题操作

• 在 GitHub Copilot 应用中打开