Codex CLI 偷偷驻留后台｜如何停止及自动更新注意事项
機械翻訳 / Machine-translated
A
AI Friends
20時間前・8分で読める
機械翻訳 / Machine-translated
@aifriends
AI Friends（https://aifriends.jp）のクロスポスト公式アカウント。AIツールの紹介・使い方・できることを、中学生でもわかるやさしい日本語で届けます。
明明已经关闭了终端，AI 程序却还在运行——听起来是不是有些令人不安？OpenAI 的编程工具「Codex CLI」正在发生这样的情况。本文将梳理究竟发生了什么，以及如何停止它。
Codex CLI（在终端中运行的 AI 编程助手）的新版本中，后台常驻程序已默认启用。
常驻程序被称为「守护进程（Daemon）」，是指不显示在界面上、持续在后台运行的程序。
这一话题由 GIGAZINE 于 2026 年 10 月 15 日报道，在开发者之间引发了广泛讨论。
起因是 GitHub 上发起的一项提案，内容是希望将其改为默认关闭，仅让有需要的用户选择开启。
受影响的是 0.157.0 版本及之后的版本，该版本于 2026 年 9 月 25 日发布。
据解说博客 Daniel Vaughan 的文章 介绍，在上一个版本 0.156.0 中，这项功能还是仅供希望使用的用户选择的选项；到了 0.157.0，它变成了默认行为。
配置项名称为 daemon_auto_start。打开交互式会话时，若满足条件，后台服务器将自动启动。
GitHub issue #48195 的作者报告如下：
在主目录的 ~/.codex 下，会保存约 374MB 的平台包。
从该副本中，会运行一个名为 codex app-server --managed-daemon 的进程，关闭终端后也不会停止。
此外，还会运行一个检查更新的独立进程：启动后 5 分钟运行一次，之后每小时运行一次。若有新版本，则下载并重启后台服务器。
也就是说，除了通过 npm 等安装的 CLI 本体之外，还有另一个 Codex 在自行持续更新。因此，两者的版本可能会出现差异。
首先，更新重启可能导致正在进行的对话被中断。
相关 issue #40969（2026 年 8 月 26 日）中报告称：在用于远程操作的主机上，若更新触发，系统会发送退出信号并等待 60 秒，若仍未结束则强制终止。
其次，环境变量会被固定。例如，某天会话中设置的代理，可能在第二天的会话中仍然残留。
此外，还有报告指出，即使执行 daemon stop 停止后，检查更新的进程仍然残留的 bug。
试想这样一个场景：切换了公司 VPN，但只有 Codex 还在尝试连接旧代理而失败。在意识到原因是后台进程之前，可能要走很多弯路。
据悉，此事在 Hacker News（海外 IT 类新闻论坛）上获得了 292 条评论和 599 分。
评论中不满之声居多：
.git 变为只读，导致每隔数小时工作就被中断另一方面，也有评论指出「Claude Code 也会残留旧版本或后台进程」，认为这不只是 Codex 独有的问题。
截至本文撰写时，未能确认 OpenAI 的官方说明。在 issue 的讨论中，也未见维护者的回复。
有人还指出，官方配置参考文档中并未列出 daemon_auto_start，0.157.0 的发布说明也只是一笔带过。
另据 GIGAZINE 报道，在提交日志中发现了一项「默认不自动启动」的改动，或许正在推进相应处理。但目前尚未确认修复已经发布。
官方尚未提供禁用方式。不过，已有多份报告表明可以通过配置标志来停止。
最简便的方法是在配置文件 ~/.codex/config.toml 中写入以下两行：
[features]
daemon_auto_start = false
issue 发布者整理的命令行步骤如下：
codex features disable daemon_auto_start
codex app-server daemon stop
pkill -f 'app-server daemon pid-update-loop'
rm -rf ~/.codex/packages/app-server-daemon
第 1 行关闭功能，第 2 行停止正在运行的常驻程序，第 3 行终止残留的更新检查进程，第 4 行删除已保存的包。
DevelopersDigest 也介绍了这一步骤，但注明作者本人未能复现。
有两点注意事项：配置项名称的写法因信息来源不同而有所差异，Vaughan 的文章中给出了另一种写法，请以您所使用的版本为准确认。
另外，rm -rf 若误删位置会造成危险，执行前请务必仔细确认路径。
停止后，重新启动 Codex，用 ps 确认。若没有出现 app-server 进程则表示成功。
AI 编程工具的更新方式大致分为三类：
Hacker News 的评论中，有开发者写道「选择了启动时检查而非常驻方式」，理由之一是常驻进程容易被杀毒软件误报。
常驻方式也有其优点。据 Vaughan 的文章介绍，启动速度更快、关闭终端后工作可继续、多个标签页可共享同一服务器。
也就是说，问题在于以便利性为代价，程序在用户不可见的地方运行。
尤其是像 nix 或 Homebrew 那样希望「固定版本」的用户会面临困扰，因为后台自更新会绕过固定的版本。
这对日本开发者来说也不是事不关己。以下列举三种容易受到影响的场景。
第一，在公司内网工作的工程师。需要按日切换代理设置的人，容易遭遇旧设置残留的问题。
第二，信息系统部门。未经授权的程序常驻后台并每小时对外通信，可能在审计时被要求作出说明。
第三，使用公司电脑工作的自由职业者。在磁盘空间不足的笔记本电脑上，除了 374MB 的保存空间外，旧版本不断堆积，可能在不知不觉中耗尽剩余空间。
应对方法很简单：若团队共同使用，在配置文件分发或内部操作规程中加入 daemon_auto_start = false 即可放心使用。
可以认为这是 OpenAI 有意加入的标准功能。据悉，0.157.0 的发布说明中也有一句提及后台服务器自动启动的内容。不过，由于说明过少，也出现了「看起来像恶意软件」的批评声音。
受影响的是 0.157.0 及之后版本的交互式会话。据称，一次性执行命令的 codex exec 不受影响。
据报告，只是新会话不会再启动后台服务器。issue 发布者写道，使用该设置后，新窗口中不再出现常驻程序。
目前尚未确认官方公告。issue #48195 在本文撰写时仍处于开放状态。更新信息请关注 GitHub 的发布说明。
首先，请在终端中执行 ps，确认自己的环境中是否残留有 app-server 进程。
本文转载自 AI Friends。