先说结论这个报错不是 codex 功能坏了也不是你的网络有问题而是 Windows 把 codex 要拉起的后台守护进程daemon process给拦了下来。绝大多数情况下问题出在权限层级、目录写权限或杀毒软件实时防护这三者之一。本文会把整个排查链路、根因分析和 Windows 下的干净安装做法完整讲清楚适合在 Windows 上安装和使用 codex cli 时遇到同样报错、或者准备入坑但还没踩到这一步的朋友。1. 报错现场还原codex cli 第一次运行时的 daemon 启动陷阱很多人在 Windows 上装完 codex 后兴冲冲打开终端敲下codex等来的不是交互式对话界面而是一行冷冰冰的报错Error: failed to open daemon process: 拒绝访问。(os error 5)然后终端就退出了。我当时第一次遇到这个报错时也很懵程序明明装好了codex --version能正常输出版本号为什么一启动反而报错要理解这个问题得先搞清楚 codex cli 的启动逻辑。它不是一个单进程的简单命令行工具而是典型的客户端-守护进程架构每次你在终端敲codex时主进程会尝试连接或创建一个后台 daemon。这个 daemon 负责维持会话状态、处理历史记录、和远端模型服务保持长连接。主进程和 daemon 之间通过本地回环地址或命名管道通信所以主进程启动时第一件事就是打开这个 daemon——而failed to open daemon process就发生在这一步。1.1 报错输出的完整形态不同版本、不同终端的报错前缀可能略有差异但核心信息一致。我整理两个典型场景Error: failed to open daemon process: 拒绝访问。(os error 5)Error: failed to open daemon process: Access is denied. (os error 5)注意括号里的os error 5这是理解问题的关键线索。在 Windows 上os error 5对应系统错误码ERROR_ACCESS_DENIED翻译过来就是访问被拒绝。它和os error 13权限不足、os error 2文件不存在的性质完全不同它表示系统的访问控制机制明确拒绝了这次操作不是文件找不到、不是网络不通而是“你没有被授权做这件事”。我见过不少用户在社区里贴出这个报错后下面回复五花八门有人让重装 Node.js有人让删掉整个.codex目录还有人让换终端。这些方法偶尔能碰巧生效但都没有触及本质。与其瞎试不如先花五分钟把报错背后的机制理清楚再对症下药。1.2 为什么 codex 不能像普通命令一样直接聊天这里用一个生活化类比如果把 codex cli 比作餐厅主进程就是前台的点餐窗口daemon 是后厨。你站着点餐敲命令很快但真正出菜的是后厨daemon。点餐窗口需要先和后厨建立联系才能接单。后厨还没开火时点餐窗口要负责把后厨启动起来后厨已经在忙时点餐窗口只需要推开后厨的门把新订单递进去。codex 主进程每次启动时都会先检查本机有没有一个正在运行的 codex daemon。有就直接连接没有就要创建一个。failed to open daemon process就发生在创建 daemon 进程这一步主进程尝试CreateProcess拉起后台服务时Windows 拒绝了这次进程创建操作。这就把问题范围缩小了——不是连接失败而是创建过程被拦截。结合os error 5的语义我们可以把嫌疑锁定在几个非常具体的方向上。2. os error 5 在 Windows 上意味着什么权限问题的底层逻辑要彻底解决这个报错先得搞清楚 Windows 的权限模型和 Linux/macOS 有什么不同。很多人之前在类 Unix 系统上用惯了想当然地认为拒绝访问就是文件没权限于是在.codex目录上疯狂改属性结果毫无用处。2.1 Windows 错误码与 C 运行时错误码的对应关系os error 5这个表述来自 Go 和 Rust 这类语言在 Windows 上对系统错误的映射。Go 运行时会把 Windows API 返回的错误码直接透传给用户ERROR_ACCESS_DENIED的错误码是 5所以显示为os error 5。在 Linux 上类似的错误是EACCES权限被拒绝或EPERM操作不允许但它们的具体应用场景有很大差别。Linux 下最常见的情况是文件系统权限位不对比如~/.codex目录的所有者不是当前用户。Windows 下的拒绝访问则可能触发于更多场景当前进程权限不足无法创建子进程UAC 隔离向受保护的系统目录或注册表项写入数据杀毒软件或安全策略拦截了进程创建行为文件或目录的 ACL访问控制列表损坏命名管道或端口的绑定被安全软件抢占或拦截。所以你看拒绝访问在 Windows 上是个大箩筐什么都能装。盲目地去 chmod 或者删目录大概率修不到点子上。2.2 最容易踩的三个权限雷区基于我在 Windows 上帮人排查同类报错的经验os error 5出现在 codex 启动阶段时超过九成是以下三类原因之一第一类是终端进程本身的权限层级不对。很多人习惯在普通 PowerShell 里直接敲codex但 codex 安装到全局目录后daemon 进程的创建需要访问某些受保护资源。如果当前终端不是以管理员身份运行Windows 的用户账户控制UAC机制可能直接拒绝这次进程创建。反过来说如果你一直以管理员身份跑又可能出现另一种拒绝访问——daemon 以高权限创建的文件普通终端后续读取时不匹配。第二类是 codex 的配置目录/Users/YourName/.codex存在 ACL 异常或残留文件损坏。Windows 下用户目录本身的 ACL 一般没问题但如果你多次强行终止 codex 进程、杀毒软件误隔离了目录中的某个文件、或者之前以管理员身份运行过 codex 导致目录里产生了具有高权限所有者标记的文件后续普通权限的进程尝试访问这些文件时就会收到os error 5。第三类是杀毒软件的实时防护。Windows Defender 或第三方安全软件会监听进程创建行为。codex 主进程拉起名为codex的子进程时如果安全软件的规则认为这个行为可疑会直接返回拒绝访问而系统不会把这个拦截原因原原本本告诉用户最终呈现出来的就是一句没头没尾的os error 5。理解了这三类来源后排查顺序就很有针对性了先确认是不是最高频的权限层级问题再检查目录健康状态最后才考虑安全软件拦截。3. 由易到难的五步排查链路从管理员身份到路径权限我建议按下面的顺序排查每一步都能在一个明确的检查结果上收敛而不是漫无目的地重装。整个过程大约半小时内可以完成大部分用户到第二步就能定位根因。3.1 先做快速验证管理员身份跑一次这是最直接也最廉价的一步目的不是让你以后都用管理员跑而是用它来区分问题类别。在 Windows 上按Win X选择终端(管理员)或Windows PowerShell(管理员)然后运行codex如果你的终端不支持自动弹出 UAC 授权也可以先右键以管理员身份打开 PowerShell再执行命令。观察结果如果正常进入交互界面说明 codex 本身没有坏问题出在普通终端的权限层级上如果仍然报os error 5可以排除单纯的 UAC 层级问题继续往下查。我在这个环节见过两种情况一种是用普通终端跑不了、管理员能跑最后定位到 npm 全局目录写权限另一种是管理员也跑不了最后定位到杀毒软件把 codex 的可执行文件加入了隔离区。所以管理员验证只是定基调不是答案本身。3.2 检查 .codex 配置目录的健康状况codex 在 Windows 下的配置目录默认位于用户目录下的.codex路径一般长这样C:\Users\你的用户名\.codex先试试能否正常列出目录内容Get-ChildItem -Force $env:USERPROFILE\.codex如果能列出来重点看两件事一是目录里有没有可疑的残留进程文件比如daemon.pid、.lock、*.sock之类二是有没有文件处于只读或大小异常的状态。如果列目录本身就报错比如提示拒绝访问那就是目录的 ACL 出了问题。这种情况下的处理办法是先把配置文件备份出来再重命名整个目录让 codex 重新生成一份。备份是必须的因为里面存了历史会话数据直接删除很可惜Copy-Item $env:USERPROFILE\.codex $env:USERPROFILE\.codex.bak -Recurse Rename-Item $env:USERPROFILE\.codex $env:USERPROFILE\.codex.old之后重新运行codex它会建一个全新的空配置目录。如果问题不再出现说明旧目录里确实有损坏的残留文件。导出的备份还可以从中找回之前的会话记录。3.3 查杀毒软件拦截记录这一环节非常关键尤其当你安装了第三方杀毒软件且上面的管理员验证失败了。Windows Defender 的历史记录在设置 - 隐私和安全性 - Windows 安全中心 - 病毒和威胁防护 - 保护历史记录里。点开看看有没有与codex相关的拦截记录。如果确认是被拦截了正确做法不是关闭实时防护而是将以下路径加入排除项codex 可执行文件所在目录%USERPROFILE%\.codex配置目录Node.js 的全局安装目录。以常见 npm 全局安装位置为例排除项路径大致是C:\Users\你的用户名\AppData\Roaming\npm不同终端的安装位置可能有差异建议先执行where.exe codex看具体路径where.exe codex把输出里的实际目录加进排除项然后重新运行 codex。很多之前怎么重装都解决不了的os error 5在添加排除项之后立刻就好了原因是安全软件拦截的是进程创建这个动作而不是文件本身所以你重装多少次都没用。3.4 检查 npm 全局安装位置是否被锁死npm 全局安装目录位于Program Files下时会引入一个隐藏的权限问题。先执行npm config get prefix看到的结果大概率是下面两种之一C:\Users\你的用户名\AppData\Roaming\npm用户级目录没问题C:\Program Files\nodejs系统级目录问题预警。如果 prefix 指向Program Files说明全局 CLI 被安装在了受 UAC 保护的目录里。安装时需要管理员权限运行时普通用户进程访问这些文件也可能被策略拦一道。daemon 启动时如果尝试读取安装在Program Files下的资源文件就会诱发os error 5。我的建议是不要依赖管理员权限硬扛把全局安装位置挪到用户目录一劳永逸。具体操作如下。第一步创建用户级 npm 全局目录并配置 prefixmkdir $env:USERPROFILE\npm npm config set prefix $env:USERPROFILE\npm第二步把%USERPROFILE%\npm加入当前用户的环境变量 PATH[Environment]::SetEnvironmentVariable( Path, [Environment]::GetEnvironmentVariable(Path, User) ;$env:USERPROFILE\npm, User )之后关闭当前终端重新打开一个普通终端执行npm root -g如果输出变成C:\Users\你的用户名\npm\node_modules说明配置生效了。再重新安装 codex cli用的是你当初安装时的全局安装命令这里用占位表示npm install -g codex注意实际包名以官方安装文档为准这里的命令只是示意。装完再跑codex很大概率不再报 daemon 启动错误。3.5 检查残留进程和僵死 daemon有时候问题不是没权限创建进程而是上一次运行产生了一个僵死的 daemon占据了资源新的 daemon 无法启动。先看看有没有残留进程Get-Process | Where-Object { $_.ProcessName -like *codex* }如果有直接结束Get-Process | Where-Object { $_.ProcessName -like *codex* } | Stop-Process接着检查本地端口占用。codex daemon 会监听一个本地回环端口如果看到大量 TIME_WAIT 或 ESTABLISHED 状态的连接集中在某几个端口而对应进程又已经不存在那就是残留 socket 没清干净。重启电脑是解决这类僵死状态最粗暴但有效的手段。另外如果你在配置里修改过 API 端点设置比如通过第三方兼容端点接入模型要确认这个配置项没有指向一个不可达或权限受限的地址。这类错误通常表现为请求超时或endpoint相关提示虽然和os error 5不是同一类问题但容易在一个日志文件里同时出现干扰你的排查视线。4. 根治做法Windows 下重装 codex cli 的干净路径如果上面的排查已经让你恢复了正常那这一节的内容可以当作预防性知识。如果你还在泥潭里或者想彻底重来一遍我建议按下面的方式重新搭建环境。这不仅能根治os error 5还能避免后续其他奇怪问题。4.1 推荐的终端与环境组合Windows 下 codex cli 最容易出问题的组合是老版cmd加低版本 Node.js。老旧终端在路径解析、UTF-8 编码、伪终端支持方面都有历史包袱codex 这类依赖长连接和交互式界面的工具很容易踩雷。我当前在 Windows 上稳定使用的组合是终端Windows TerminalShellPowerShell 7至少 5.1 以上Node.js偶数版本 LTS比如当前 LTS 版本npm随 Node.js 自带即可。验证命令node -v npm -v $PSVersionTable.PSVersion有人问 Git Bash 能不能用。我的建议是能跑但不要作为主力。Git Bash 对 Windows 路径的转换规则经常让 CLI 工具摸不着头脑遇到过好几次明明是本地文件路径却解析出错的问题。干脆统一在 PowerShell 里用。4.2 把全局工具链搬出 Program Files这一节是重装时的关键一步。很多教程直接告诉你以管理员身份运行 npm install -g这能装成功但会埋下一系列权限后患。正确做法是让全局工具链完全落在用户目录内。完整步骤我这里再串一遍打开普通权限的 PowerShell创建用户级全局目录mkdir $env:USERPROFILE\npm把 prefix 指过去npm config set prefix $env:USERPROFILE\npm确认生效npm config get prefix把%USERPROFILE%\npm加入用户 PATH前面已经给过环境变量的修改命令这里不再重复重新打开终端确认npm root -g指向用户目录执行全局安装命令安装 codex cli。这样安装后全局命令的入口位于普通用户可写的目录中daemon 创建时不会触碰任何受 UAC 保护的路径。整个链路从普通用户运行终端到CLI 读取资源再到daemon 创建子进程都是同一权限级别不会再出现跨权限访问被拒的问题。4.3 重新初始化配置目录并认识关键配置项重装后第一次运行 codex它会自动生成新的配置目录和配置文件。配置文件一般在C:\Users\你的用户名\.codex\config.toml如果你之前手动编辑过配置暂时不要直接复制旧配置。等新配置生效后再用备份文件逐项对照。重点关注的配置项有三个模型选择默认使用的模型名称生成参数温度、最大 token 数等第三方兼容端点如果你接入了自己的模型服务地址确认这里的配置和你的服务端匹配并且本地回环访问没有被安全策略拦截。网上可以搜到大量现成的配置模板但我不建议无脑 copy。不同版本、不同模型网关的字段名有差异复制来路不明的配置很可能引入新的启动错误。先把最小配置跑起来再一项项加自己需要的。4.4 防火墙出站规则也值得顺手确认权限问题解决后如果你发现 codex daemon 能启动但请求总是卡住或者超时可以顺手检查一下 Windows 防火墙的出站规则。按Win R输入firewall.cpl进入允许应用通过防火墙看看 codex 的可执行文件是否被阻止。一般家庭网络下Windows 防火墙很少拦截新程序的出站连接但如果在公司或校园网络环境里安全策略可能默认阻止未识别的程序联网。这一步和os error 5没有直接因果关系但我在一次排查中确实见过用户解决了 daemon 启动问题后又遇到请求超时绕了一圈才发现是防火墙阻止了 codex 的对外连接。既然已经走到这里顺手排掉这个不确定因素省得以后再把错误归咎到权限上。5. 复盘与实用习惯避坑之后我给新手的几条操作建议踩过os error 5这个坑之后我复盘了整个排查过程有个很深的体会在 Windows 上排查这类问题最关键的不是记住某条具体命令而是建立一种分层定位的思维。先确认是权限层级问题、还是目录状态问题、还是安全软件拦截问题再动刀效率远比反复重装高得多。5.1 这个坑为什么容易反复踩其实说白了failed to open daemon process: 拒绝访问。(os error 5)在 Windows 上之所以高发是因为 codex 的客户端-守护进程架构在 Windows 的权限模型下多了一层不确定性。类 Unix 系统下用户级 daemon 写用户目录天经地义几乎不需要额外授权Windows 下则不然UAC、防病毒软件、目录 ACL 都可能成为拦截点。很多用户在这一步折戟还有一个重要原因是网上的通用教程大多以 macOS 或 Linux 为主到 Windows 部分往往只有一句以管理员身份运行这句话治标不治本。以管理员身份运行确实能绕过一部分权限问题但后续 daemon 以高权限创建的文件、缓存、日志会让普通用户身份的下一次运行遇到新的权限不匹配反而让错误变得更隐蔽。5.2 建议的日常操作习惯结合我自己的使用经验给你几个能长期减少这类问题的习惯第一不要用管理员终端跑日常的 codex。管理员权限是用来安装工具链和调试系统问题的不是用来写代码的。把 npm prefix 配置到用户目录后普通终端就能顺畅运行根本不需要管理员。第二遇到 拒绝访问 先去看安全软件的保护历史而不是急着重装。杀毒软件的拦截提示虽然经常藏得有点深但它是唯一能直接证明某个行为被拦截的记录。第三定期查看 codex 配置目录下的日志文件。日志一般位于配置目录的日志子目录中按时间戳命名。报错不一定只出现在终端上后台 daemon 发生的问题往往只记录在自己的日志中。学会看日志排错效率能提升一整档。第四不要在配置里堆你自己都不理解的参数。许多高级配置项和第三方模型网关相关配置不当会导致各种诡异的启动失败。新增配置前先确认自己了解它的作用并在修改前备份config.toml。最后说一个我自己体会最深的小技巧每次升级 Node.js 或重装 codex cli 之后别急着恢复旧配置先用默认配置跑通一条最简单的对话。确认最小功能正常后再逐步加配置。这样做的好处是一旦出问题你至少知道是新版本不兼容旧配置还是环境本身有问题不至于把时间浪费在无效排查上。 先说结论这个报错不是 codex 功能坏了也不是你的网络有问题而是 Windows 把 codex 要拉起的后台守护进程daemon process给拦了下来。绝大多数情况下问题出在权限层级、目录写权限或杀毒软件实时防护这三者之一。本文会把整个排查链路、根因分析和 Windows 下的干净安装做法完整讲清楚适合在 Windows 上安装和使用 codex cli 时遇到同样报错、或者准备入坑但还没踩到这一步的朋友。1. 报错现场还原codex cli 第一次运行时的 daemon 启动陷阱很多人在 Windows 上装完 codex 后兴冲冲打开终端敲下codex等来的不是交互式对话界面而是一行冷冰冰的报错Error: failed to open daemon process: 拒绝访问。(os error 5)然后终端就退出了。我当时第一次遇到这个报错时也很懵程序明明装好了codex --version能正常输出版本号为什么一启动反而报错要理解这个问题得先搞清楚 codex cli 的启动逻辑。它不是一个单进程的简单命令行工具而是典型的客户端-守护进程架构每次你在终端敲codex时主进程会尝试连接或创建一个后台 daemon。这个 daemon 负责维持会话状态、处理历史记录、和远端模型服务保持长连接。主进程和 daemon 之间通过本地回环地址或命名管道通信所以主进程启动时第一件事就是打开这个 daemon——而failed to open daemon process就发生在这一步。1.1 报错输出的完整形态不同版本、不同终端的报错前缀可能略有差异但核心信息一致。我整理两个典型场景Error: failed to open daemon process: 拒绝访问。(os error 5)Error: failed to open daemon process: Access is denied. (os error 5)注意括号里的os error 5这是理解问题的关键线索。在 Windows 上os error 5对应系统错误码ERROR_ACCESS_DENIED翻译过来就是访问被拒绝。它和os error 13权限不足、os error 2文件不存在的性质完全不同它表示系统的访问控制机制明确拒绝了这次操作不是文件找不到、不是网络不通而是“你没有被授权做这件事”。我见过不少用户在社区里贴出这个报错后下面回复五花八门有人让重装 Node.js有人让删掉整个.codex目录还有人让换终端。这些方法偶尔能碰巧生效但都没有触及本质。与其瞎试不如先花五分钟把报错背后的机制理清楚再对症下药。1.2 为什么 codex 不能像普通命令一样直接聊天这里用一个生活化类比如果把 codex cli 比作餐厅主进程就是前台的点餐窗口daemon 是后厨。你站着点餐敲命令很快但真正出菜的是后厨daemon。点餐窗口需要先和后厨建立联系才能接单。后厨还没开火时点餐窗口要负责把后厨启动起来后厨已经在忙时点餐窗口只需要推开后厨的门把新订单递进去。codex 主进程每次启动时都会先检查本机有没有一个正在运行的 codex daemon。有就直接连接没有就要创建一个。failed to open daemon process就发生在创建 daemon 进程这一步主进程尝试CreateProcess拉起后台服务时Windows 拒绝了这次进程创建操作。这就把问题范围缩小了——不是连接失败而是创建过程被拦截。结合os error 5的语义我们可以把嫌疑锁定在几个非常具体的方向上。2. os error 5 在 Windows 上意味着什么权限问题的底层逻辑要彻底解决这个报错先得搞清楚 Windows 的权限模型和 Linux/macOS 有什么不同。很多人之前在类 Unix 系统上用惯了想当然地认为拒绝访问就是文件没权限于是在.codex目录上疯狂改属性结果毫无用处。2.1 Windows 错误码与 C 运行时错误码的对应关系os error 5这个表述来自 Go 和 Rust 这类语言在 Windows 上对系统错误的映射。Go 运行时会把 Windows API 返回的错误码直接透传给用户ERROR_ACCESS_DENIED的错误码是 5所以显示为os error 5。在 Linux 上类似的错误是EACCES权限被拒绝或EPERM操作不允许但它们的具体应用场景有很大差别。Linux 下最常见的情况是文件系统权限位不对比如~/.codex目录的所有者不是当前用户。Windows 下的拒绝访问则可能触发于更多场景当前进程权限不足无法创建子进程UAC 隔离向受保护的系统目录或注册表项写入数据杀毒软件或安全策略拦截了进程创建行为文件或目录的 ACL访问控制列表损坏命名管道或端口的绑定被安全软件抢占或拦截。所以你看拒绝访问在 Windows 上是个大箩筐什么都能装。盲目地去 chmod 或者删目录大概率修不到点子上。2.2 最容易踩的三个权限雷区基于我在 Windows 上帮人排查同类报错的经验os error 5出现在 codex 启动阶段时超过九成是以下三类原因之一第一类是终端进程本身的权限层级不对。很多人习惯在普通 PowerShell 里直接敲codex但 codex 安装到全局目录后daemon 进程的创建需要访问某些受保护资源。如果当前终端不是以管理员身份运行Windows 的用户账户控制UAC机制可能直接拒绝这次进程创建。反过来说如果你一直以管理员身份跑又可能出现另一种拒绝访问——daemon 以高权限创建的文件普通终端后续读取时不匹配。第二类是 codex 的配置目录/Users/YourName/.codex存在 ACL 异常或残留文件损坏。Windows 下用户目录本身的 ACL 一般没问题但如果你多次强行终止 codex 进程、杀毒软件误隔离了目录中的某个文件、或者之前以管理员身份运行过 codex 导致目录里产生了具有高权限所有者标记的文件后续普通权限的进程尝试访问这些文件时就会收到os error 5。第三类是杀毒软件的实时防护。Windows Defender 或第三方安全软件会监听进程创建行为。codex 主进程拉起名为codex的子进程时如果安全软件的规则认为这个行为可疑会直接返回拒绝访问而系统不会把这个拦截原因原原本本告诉用户最终呈现出来的就是一句没头没尾的os error 5。理解了这三类来源后排查顺序就很有针对性了先确认是不是最高频的权限层级问题再检查目录健康状态最后才考虑安全软件拦截。3. 由易到难的五步排查链路从管理员身份到路径权限我建议按下面的顺序排查每一步都能在一个明确的检查结果上收敛而不是漫无目的地重装。整个过程大约半小时内可以完成大部分用户到第二步就能定位根因。3.1 先做快速验证管理员身份跑一次这是最直接也最廉价的一步目的不是让你以后都用管理员跑而是用它来区分问题类别。在 Windows 上按Win X选择终端(管理员)或Windows PowerShell(管理员)然后运行codex如果你的终端不支持自动弹出 UAC 授权也可以先右键以管理员身份打开 PowerShell再执行命令。观察结果如果正常进入交互界面说明 codex 本身没有坏问题出在普通终端的权限层级上如果仍然报os error 5可以排除单纯的 UAC 层级问题继续往下查。我在这个环节见过两种情况一种是用普通终端跑不了、管理员能跑最后定位到 npm 全局目录写权限另一种是管理员也跑不了最后定位到杀毒软件把 codex 的可执行文件加入了隔离区。所以管理员验证只是定基调不是答案本身。3.2 检查 .codex 配置目录的健康状况codex 在 Windows 下的配置目录默认位于用户目录下的.codex路径一般长这样C:\Users\你的用户名\.codex先试试能否正常列出目录内容Get-ChildItem -Force $env:USERPROFILE\.codex如果能列出来重点看两件事一是目录里有没有可疑的残留进程文件比如daemon.pid、.lock、*.sock之类二是有没有文件处于只读或大小异常的状态。如果列目录本身就报错比如提示拒绝访问那就是目录的 ACL 出了问题。这种情况下的处理办法是先把配置文件备份出来再重命名整个目录让 codex 重新生成一份。备份是必须的因为里面存了历史会话数据直接删除很可惜Copy-Item $env:USERPROFILE\.codex $env:USERPROFILE\.codex.bak -Recurse Rename-Item $env:USERPROFILE\.codex $env:USERPROFILE\.codex.old之后重新运行codex它会建一个全新的空配置目录。如果问题不再出现说明旧目录里确实有损坏的残留文件。导出的备份还可以从中找回之前的会话记录。3.3 查杀毒软件拦截记录这一环节非常关键尤其当你安装了第三方杀毒软件且上面的管理员验证失败了。Windows Defender 的历史记录在设置 - 隐私和安全性 - Windows 安全中心 - 病毒和威胁防护 - 保护历史记录里。点开看看有没有与codex相关的拦截记录。如果确认是被拦截了正确做法不是关闭实时防护而是将以下路径加入排除项codex 可执行文件所在目录%USERPROFILE%\.codex配置目录Node.js 的全局安装目录。以常见 npm 全局安装位置为例排除项路径大致是C:\Users\你的用户名\AppData\Roaming\npm不同终端的安装位置可能有差异建议先执行where.exe codex看具体路径where.exe codex把输出里的实际目录加进排除项然后重新运行 codex。很多之前怎么重装都解决不了的os error 5在添加排除项之后立刻就好了原因是安全软件拦截的是进程创建这个动作而不是文件本身所以你重装多少次都没用。3.4 检查 npm 全局安装位置是否被锁死npm 全局安装目录位于Program Files下时会引入一个隐藏的权限问题。先执行npm config get prefix看到的结果大概率是下面两种之一C:\Users\你的用户名\AppData\Roaming\npm用户级目录没问题C:\Program Files\nodejs系统级目录问题预警。如果 prefix 指向Program Files说明全局 CLI 被安装在了受 UAC 保护的目录里。安装时需要管理员权限运行时普通用户进程访问这些文件也可能被策略拦一道。daemon 启动时如果尝试读取安装在Program Files下的资源文件就会诱发os error 5。我的建议是不要依赖管理员权限硬扛把全局安装位置挪到用户目录一劳永逸。具体操作如下。第一步创建用户级 npm 全局目录并配置 prefixmkdir $env:USERPROFILE\npm npm config set prefix $env:USERPROFILE\npm第二步把%USERPROFILE%\npm加入当前用户的环境变量 PATH[Environment]::SetEnvironmentVariable( Path, [Environment]::GetEnvironmentVariable(Path, User) ;$env:USERPROFILE\npm, User )之后关闭当前终端重新打开一个普通终端执行npm root -g如果输出变成C:\Users\你的用户名\npm\node_modules说明配置生效了。再重新安装 codex cli用的是你当初安装时的全局安装命令这里用占位表示npm install -g codex注意实际包名以官方安装文档为准这里的命令只是示意。装完再跑codex很大概率不再报 daemon 启动错误。3.5 检查残留进程和僵死 daemon有时候问题不是没权限创建进程而是上一次运行产生了一个僵死的 daemon占据了资源新的 daemon 无法启动。先看看有没有残留进程Get-Process | Where-Object { $_.ProcessName -like *codex* }如果有直接结束Get-Process | Where-Object { $_.ProcessName -like *codex* } | Stop-Process接着检查本地端口占用。codex daemon 会监听一个本地回环端口如果看到大量 TIME_WAIT 或 ESTABLISHED 状态的连接集中在某几个端口而对应进程又已经不存在那就是残留 socket 没清干净。重启电脑是解决这类僵死状态最粗暴但有效的手段。另外如果你在配置里修改过 API 端点设置比如通过第三方兼容端点接入模型要确认这个配置项没有指向一个不可达或权限受限的地址。这类错误通常表现为请求超时或endpoint相关提示虽然和os error 5不是同一类问题但容易在一个日志文件里同时出现干扰你的排查视线。4. 根治做法Windows 下重装 codex cli 的干净路径如果上面的排查已经让你恢复了正常那这一节的内容可以当作预防性知识。如果你还在泥潭里或者想彻底重来一遍我建议按下面的方式重新搭建环境。这不仅能根治os error 5还能避免后续其他奇怪问题。4.1 推荐的终端与环境组合Windows 下 codex cli 最容易出问题的组合是老版cmd加低版本 Node.js。老旧终端在路径解析、UTF-8 编码、伪终端支持方面都有历史包袱codex 这类依赖长连接和交互式界面的工具很容易踩雷。我当前在 Windows 上稳定使用的组合是终端Windows TerminalShellPowerShell 7至少 5.1 以上Node.js偶数版本 LTS比如当前 LTS 版本npm随 Node.js 自带即可。验证命令node -v npm -v $PSVersionTable.PSVersion有人问 Git Bash 能不能用。我的建议是能跑但不要作为主力。Git Bash 对 Windows 路径的转换规则经常让 CLI 工具摸不着头脑遇到过好几次明明是本地文件路径却解析出错的问题。干脆统一在 PowerShell 里用。4.2 把全局工具链搬出 Program Files这一节是重装时的关键一步。很多教程直接告诉你以管理员身份运行 npm install -g这能装成功但会埋下一系列权限后患。正确做法是让全局工具链完全落在用户目录内。完整步骤我这里再串一遍打开普通权限的 PowerShell创建用户级全局目录mkdir $env:USERPROFILE\npm把 prefix 指过去npm config set prefix $env:USERPROFILE\npm确认生效npm config get prefix把%USERPROFILE%\npm加入用户 PATH前面已经给过环境变量的修改命令这里不再重复重新打开终端确认npm root -g指向用户目录执行全局安装命令安装 codex cli。这样安装后全局命令的入口位于普通用户可写的目录中daemon 创建时不会触碰任何受 UAC 保护的路径。整个链路从普通用户运行终端到CLI 读取资源再到daemon 创建子进程都是同一权限级别不会再出现跨权限访问被拒的问题。4.3 重新初始化配置目录并认识关键配置项重装后第一次运行 codex它会自动生成新的配置目录和配置文件。配置文件一般在C:\Users\你的用户名\.codex\config.toml如果你之前手动编辑过配置暂时不要直接复制旧配置。等新配置生效后再用备份文件逐项对照。重点关注的配置项有三个模型选择默认使用的模型名称生成参数温度、最大 token 数等第三方兼容端点如果你接入了自己的模型服务地址确认这里的配置和你的服务端匹配并且本地回环访问没有被安全策略拦截。网上可以搜到大量现成的配置模板但我不建议无脑 copy。不同版本、不同模型网关的字段名有差异复制来路不明的配置很可能引入新的启动错误。先把最小配置跑起来再一项项加自己需要的。4.4 防火墙出站规则也值得顺手确认权限问题解决后如果你发现 codex daemon 能启动但请求总是卡住或者超时可以顺手检查一下 Windows 防火墙的出站规则。按Win R输入firewall.cpl进入允许应用通过防火墙看看 codex 的可执行文件是否被阻止。一般家庭网络下Windows 防火墙很少拦截新程序的出站连接但如果在公司或校园网络环境里安全策略可能默认阻止未识别的程序联网。这一步和os error 5没有直接因果关系但我在一次排查中确实见过用户解决了 daemon 启动问题后又遇到请求超时绕了一圈才发现是防火墙阻止了 codex 的对外连接。既然已经走到这里顺手排掉这个不确定因素省得以后再把错误归咎到权限上。5. 复盘与实用习惯避坑之后我给新手的几条操作建议踩过os error 5这个坑之后我复盘了整个排查过程有个很深的体会在 Windows 上排查这类问题最关键的不是记住某条具体命令而是建立一种分层定位的思维。先确认是权限层级问题、还是目录状态问题、还是安全软件拦截问题再动刀效率远比反复重装高得多。5.1 这个坑为什么容易反复踩其实说白了failed to open daemon process: 拒绝访问。(os error 5)在 Windows 上之所以高发是因为 codex 的客户端-守护进程架构在 Windows 的权限模型下多了一层不确定性。类 Unix 系统下用户级 daemon 写用户目录天经地义几乎不需要额外授权Windows 下则不然UAC、防病毒软件、目录 ACL 都可能成为拦截点。很多用户在这一步折戟还有一个重要原因是网上的通用教程大多以 macOS 或 Linux 为主到 Windows 部分往往只有一句以管理员身份运行这句话治标不治本。以管理员身份运行确实能绕过一部分权限问题但后续 daemon 以高权限创建的文件、缓存、日志会让普通用户身份的下一次运行遇到新的权限不匹配反而让错误变得更隐蔽。5.2 建议的日常操作习惯结合我自己的使用经验给你几个能长期减少这类问题的习惯第一不要用管理员终端跑日常的 codex。管理员权限是用来安装工具链和调试系统问题的不是用来写代码的。把 npm prefix 配置到用户目录后普通终端就能顺畅运行根本不需要管理员。第二遇到 拒绝访问 先去看安全软件的保护历史而不是急着重装。杀毒软件的拦截提示虽然经常藏得有点深但它是唯一能直接证明某个行为被拦截的记录。第三定期查看 codex 配置目录下的日志文件。日志一般位于配置目录的日志子目录中按时间戳命名。报错不一定只出现在终端上后台 daemon 发生的问题往往只记录在自己的日志中。学会看日志排错效率能提升一整档。第四不要在配置里堆你自己都不理解的参数。许多高级配置项和第三方模型网关相关配置不当会导致各种诡异的启动失败。新增配置前先确认自己了解它的作用并在修改前备份config.toml。最后说一个我自己体会最深的小技巧每次升级 Node.js 或重装 codex cli 之后别急着恢复旧配置先用默认配置跑通一条最简单的对话。确认最小功能正常后再逐步加配置。这样做的好处是一旦出问题你至少知道是新版本不兼容旧配置还是环境本身有问题不至于把时间浪费在无效排查上。