近期 OpenAI Codex CLI 0.157.0 版本在 Windows 平台出现启动故障，用户运行时提示 failed to open daemon process (os error 5)，即访问被拒绝，必须使用 codex –no-daemon 参数才能启动，但该模式下无法进入 agents overview 面板，回滚旧版本也无法解决。该问题在 GitHub 对应 issue 中被大量用户反馈。经排查，故障根源在于 PID 复用冲突：Codex CLI 此前运行时会在本地记录守护进程（daemon）的 PID，当守护进程退出后，Windows 会将这个 PID 重新分配给其他进程。Codex 再次启动时仍把该 PID 当作自己的守护进程进行检查，访问该系统进程时被 Windows 拒绝，从而报错。修复方法为：先关闭当前所有 Codex 相关进程（包括桌面端与 VSCode 插件），随后进入系统盘的 .codex 文件夹，删除或重命名 app-server-control 与 app-server-daemon 两个文件夹，再在终端启动 Codex，程序会重新生成守护进程的运行状态，正常情况下即可直接启动。需要注意的是，不建议直接杀掉被占用的 PID，因为该 PID 可能已被 Windows 用于挂载系统服务，强行结束可能引发系统异常。
事件分析
该故障本质上是一个典型的跨平台工程问题：Linux 与 Windows 对 PID 复用的处理行为存在差异，而 Codex CLI 长期以 macOS 和 Linux 为主要开发环境，Windows 适配成熟度不足。此次 0.157.0 引入守护进程架构后问题集中爆发，也反映出 AI 编程工具在快速迭代节奏下测试覆盖的短板。从用户侧看，删除状态文件夹的本质是清除陈旧的进程记录，属于绕过性修复，官方后续大概率会在版本更新中加入 PID 有效性校验与状态自愈机制。随着 Codex 与 Claude Code 等 AI 编程工具竞争加剧，跨平台稳定性与工程质量正成为影响开发者留存的关键变量，基础缺陷的修复速度将直接影响社区口碑。
核心观点：AI 编程工具的竞争已从模型能力延伸到工程细节，一个 PID 校验缺陷就足以劝退 Windows 开发者。
原文链接：Linux.do
