Windows 下 Codex CLI 报“拒绝访问 (os error 5)”：先查入口，再查配置

Windows 下 Codex CLI 报"拒绝访问 (os error 5)"：先查入口，再查配置

上一篇我让 Codex 用 workspace-write 修一个很小的 Node.js 路由问题。那次任务没有进入读文件和改代码阶段，CLI 在初始化 in-process app-server client 时直接返回：

text 复制代码

拒绝访问。 (os error 5)

这次我不急着重跑修改任务，先把 Windows 上最容易混在一起的几件事拆开：当前到底调用了哪个 codex，机器上有几套入口，配置目录在哪里，以及 exec --sandbox 和 sandbox 命令分别管什么。

先说目前能确认的结果：本机 PATH 中同时存在 npm 入口和 WindowsApps 入口；当前 PowerShell 实际调用的是 C:\nvm4w\nodejs\codex.ps1，版本为 codex-cli 0.147.0；默认 Codex 配置目录存在，config.toml 也存在。至于上一轮的 os error 5 究竟由哪个入口、哪个本地组件或哪个权限环节触发，当前还不能只凭这几条检查下结论。

先回看真实失败

上一轮记录的环境和结果是：

Codex CLI：0.145.0
任务权限：--sandbox workspace-write
任务目录：codes/codex-access-denied-demo/，无密钥的 Node.js 示例项目
退出码：1
失败阶段：初始化 in-process app-server client
文件变化：没有进入代码修改阶段，项目文件未被修改

当时的命令大致是：

powershell 复制代码

codex exec `
  --sandbox workspace-write `
  --ephemeral `
  --cd .\codes\codex-access-denied-demo `
  "只允许修改 src/server.js，修复测试指出的路由问题，并运行 npm test"

这不是一次"改完但测试失败"的结果。它连项目文件都没有开始处理，所以不能把后面的人工修复写成 Codex 的成功输出。排查时也应该保留这条边界：启动失败、模型请求失败、工具执行失败和代码测试失败，不是同一种故障。

第一步：确认 PowerShell 实际调用哪个入口

先在当前 PowerShell 里运行：

powershell 复制代码

Get-Command codex -All |
  Select-Object Name, CommandType, Source, Definition

where.exe codex

codex --version

我这次得到的关键信息是：

text 复制代码

当前命令：C:\nvm4w\nodejs\codex.ps1
版本：codex-cli 0.147.0

where.exe codex 还列出了同一 npm 目录下的 codex、codex.cmd，以及 WindowsApps 目录下的 codex 和 codex.exe。这说明机器上至少能看到两组来源，但它们不一定会被当前 shell 按同样顺序调用。

图 1：Get-Command 和 where.exe 的真实输出整理图。WindowsApps 的安装目录使用 ... 脱敏，命令类型和版本保留。

这里有一个容易忽略的地方：PowerShell 的 Get-Command 和 Windows 自带的 where.exe 解决的是相近但不完全相同的问题。前者告诉我当前 shell 的命令解析结果，后者告诉我 PATH 上能找到哪些匹配文件。两边只看一边，可能漏掉另一套入口。

如果要临时验证某一个入口，可以显式写完整路径：

powershell 复制代码

& "C:\nvm4w\nodejs\codex.cmd" --version

这里的路径只是我本机的实际示例。你的 npm、nvm 或桌面端安装位置可能不同，先用上面的命令查到路径，再替换进去。不要因为看到多个入口就直接删除文件或改系统 PATH。

第二步：确认当前版本支持哪些参数

我继续查看当前版本帮助：

powershell 复制代码

codex exec --help
codex sandbox --help

当前 codex exec --help 明确列出了：

text 复制代码

--sandbox <SANDBOX_MODE>
    read-only, workspace-write, danger-full-access

--cd <DIR>
--ephemeral
--ignore-user-config
--skip-git-repo-check

当前 codex sandbox --help 是另一个命令。它的用途是把一个具体的命令放进 Codex 提供的 Windows 受限令牌沙箱里运行，不等于 codex exec --sandbox 为代理任务选择的权限模式。

图 2：本机 codex-cli 0.147.0 的 exec 帮助输出。这里没有执行危险参数。

这两个名字很像，排错时却不能混用。文章、脚本和笔记里最好把完整命令写出来，先确认自己是在设置代理任务权限，还是单独运行一个受限本地命令。

我也没有使用下面这个选项：

text 复制代码

--dangerously-bypass-approvals-and-sandbox

它会跳过确认并取消沙箱。一个初始化错误还没有定位清楚时，扩大权限不能证明问题出在哪里，也会让后面的结果失去比较价值。

第三步：只确认配置路径，不把配置内容贴出来

Codex 默认使用用户目录下的 .codex。如果设置了 CODEX_HOME，则以环境变量指定的目录为准。可以只检查路径和文件是否存在：

powershell 复制代码

$codeHome = if ($env:CODEX_HOME) {
  $env:CODEX_HOME
} else {
  Join-Path $env:USERPROFILE ".codex"
}

$configPath = Join-Path $codeHome "config.toml"

[PSCustomObject]@{
  CODEX_HOME_SET = [bool]$env:CODEX_HOME
  CODEX_HOME_EXISTS = Test-Path -LiteralPath $codeHome
  CONFIG_EXISTS = Test-Path -LiteralPath $configPath
} | Format-List

我这次的结果是：没有设置 CODEX_HOME，默认 .codex 目录存在，config.toml 存在。

图 3：只记录环境变量和路径存在性，没有读取 config.toml、认证文件或日志内容。

这只能证明配置文件的位置可找到，不能证明配置内容正确，也不能证明认证、模型服务或本地进程初始化没有问题。config.toml、认证文件和日志都可能包含不适合公开的内容，不能把它们整段复制到文章、工单、截图或 Git 仓库。

如果确实要修改配置，先做备份，再逐项改动：

powershell 复制代码

$backupPath = "$configPath.bak-$(Get-Date -Format yyyyMMddHHmmss)"
Copy-Item -LiteralPath $configPath -Destination $backupPath

备份文件也不要提交 Git 或上传。修改后重新打开一个 PowerShell 窗口，再执行 codex --version 和 codex exec --help，先确认入口没有变化，再考虑做模型请求测试。

把错误分成四层

我现在会按下面的顺序看错误：

层级	先看什么	当前是否已证明
命令入口	`Get-Command codex -All`、`where.exe codex`	已确认存在多组入口
CLI 版本和参数	`codex --version`、`codex exec --help`	已确认当前为 0.147.0
本地配置和文件访问	`CODEX_HOME`、`config.toml` 是否存在	已确认路径和文件存在
任务实际执行	重新运行同一条受限任务并记录阶段	尚未完成

上一轮的 拒绝访问 (os error 5) 出现在第四层之前的初始化阶段。它不是 Node.js 测试断言，也不是 /api/books 路由返回的 HTTP 错误。当前检查能缩小排查范围，但还不能替它指定一个唯一根因。

图 4：上一篇实测的失败记录。Codex CLI 0.145.0 在初始化阶段退出，退出码为 1，没有进入代码修改阶段。

下一次重试，我会固定变量

如果要继续验证，我会保留同一个示例项目、同一条任务说明和同一个沙箱级别，只替换一个变量：显式调用已查到的入口。每次都记录：

text 复制代码

入口完整路径
codex --version
codex exec 参数
退出码
是否产生文件变化
失败发生在哪个阶段

第一次先用 read-only 做无害检查，确认 CLI 能否完成初始化；通过后再考虑 workspace-write。每次任务前后都运行：

powershell 复制代码

git status --short

示例目录如果没有 Git 基线，也要用哈希或文件副本做前后对比。没有看到真实返回内容之前，我不会写"Codex 已经修复"或"切换入口解决了问题"。

当前结论

这次排查已经确认了三件事：

本机 PATH 中同时存在 npm 和 WindowsApps 两组 Codex 入口。
当前 PowerShell 通过 C:\nvm4w\nodejs\codex.ps1 调用 codex-cli 0.147.0。
默认 .codex 配置目录和 config.toml 存在，但内容没有被公开或写入文章。

还没有确认的是 os error 5 的唯一根因，也没有新的 workspace-write 成功结果。这篇先停在可复核的排查清单，后续重试成功后再补真实终端输出，不用推测填空。

llapi.org 放在哪里

Codex CLI 使用哪个模型服务和 API Key，取决于你的本地配置。若你使用 llapi.org，

文章和截图只使用占位符：

text 复制代码

请到llapi.org 查看当前申请入口、Base URL、支持模型和服务规则。
<YOUR_LLAPI_API_KEY>

不要把真实 API Key、Authorization 头、Cookie、配置文件原文或后台截图发给别人。需要排错时，只提供脱敏后的命令、版本、错误阶段和退出码。

你在 Windows 上遇到 Codex 启动错误时，先运行 Get-Command codex -All，通常比直接重装更快知道自己到底在调用哪一份程序。

示例代码

本文使用的独立项目已放在 Gitee：

gitee.com/heihei_66/c...