1. Windows 下 Codex CLI 报 os error 5 到底卡在哪一层Codex CLI 是 OpenAI 推出的命令行编码代理工具能在终端里直接读文件、改代码、跑测试适合习惯用 PowerShell 或 CMD 做开发的 Windows 用户。但很多人第一次在 Windows 上跑codex exec时还没进入改代码阶段就直接被一句「拒绝访问。(os error 5)」拦下来。这个报错是 Windows 的权限错误码含义是当前进程没有权限访问某个资源但 Codex CLI 本身不会告诉你它到底想访问什么所以看起来像玄学。我实测下来这个错误在 Windows 上通常来自三个层面入口层你调用的到底是哪个 codex、配置层config.toml 和 settings.json 骨架是否有冲突、通道层模型请求的 Key 和 Base URL 是否统一收口。三层里任何一层出问题都可能以同一个 os error 5 的形式暴露出来所以排查顺序必须是先入口、再配置、最后收口不能一上来就重装或者改系统 PATH。这篇会给出可复制的 config.toml 片段、PowerShell 验证命令以及逐步复现和修复的动作。目标很明确让你一次定位权限与配置的冲突点而不是反复试错。如果你还没装 Codex CLI建议先把 Node.js 和 npm 装好再回来看这篇排查。2. 先查入口PowerShell 实际调用的是哪个 codexWindows 上最容易踩的坑就是机器里同时存在多套 Codex 入口。npm 全局安装会生成codex.ps1、codex.cmdWindowsApps 目录下可能还有另一份codex.exe两者版本和权限模型都不一样。PowerShell 的Get-Command和系统自带的where.exe解决的是相近但不完全相同的问题只看一边会漏掉另一套入口。先在当前 PowerShell 里运行这三条命令Get-Command codex -All | Select-Object Name, CommandType, Source, Definition where.exe codex codex --version我这边得到的典型结果是当前命令解析到C:\nvm4w\nodejs\codex.ps1版本为codex-cli 0.147.0而where.exe codex还列出了同一 npm 目录下的codex、codex.cmd以及 WindowsApps 目录下的codex和codex.exe。这说明机器上至少能看到两组来源但它们不一定被当前 shell 按同样顺序调用。如果要临时验证某一个入口显式写完整路径 C:\nvm4w\nodejs\codex.cmd --version这里的路径只是示例你的 npm、nvm 或桌面端安装位置可能不同先用上面的命令查到路径再替换。不要因为看到多个入口就直接删文件或改系统 PATH那会把问题从「调用错入口」变成「入口彻底找不到」。确认入口后再看当前版本支持哪些参数codex exec --help codex sandbox --helpcodex exec --help会列出--sandbox SANDBOX_MODEread-only、workspace-write、danger-full-access、--cd DIR、--ephemeral、--ignore-user-config、--skip-git-repo-check等。而codex sandbox --help是另一个命令用途是把一个具体命令放进 Codex 提供的 Windows 受限令牌沙箱里运行不等于codex exec --sandbox为代理任务选择的权限模式。这两个名字很像排错时不能混用。注意在初始化错误还没定位清楚之前不要使用--dangerously-bypass-approvals-and-sandbox。它会跳过确认并取消沙箱扩大权限不能证明问题出在哪里反而让后续结果失去比较价值。3. 再查配置config.toml 与 settings.json 骨架核对Codex 默认使用用户目录下的.codex如果设置了CODEX_HOME环境变量则以该变量指定的目录为准。先只检查路径和文件是否存在不要急着把内容贴出来$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这一步只能证明配置文件的位置可找到不能证明内容正确。config.toml、认证文件和日志都可能包含不适合公开的内容不要整段复制到文章、工单、截图或 Git 仓库。如果确实要修改配置先做带时间戳的备份$backupPath $configPath.bak-$(Get-Date -Format yyyyMMddHHmmss) Copy-Item -LiteralPath $configPath -Destination $backupPath下面是一份可复制的最小 config.toml 骨架把模型通道统一收口到 TaoToken避免多个 Key 和 Base URL 互相打架# ~/.codex/config.toml model gpt-4o model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chat对应的环境变量在 PowerShell 里这样设置当前会话生效$env:TAOTOKEN_API_KEY YOUR_TAOTOKEN_API_KEY如果要持久化到用户级环境变量[Environment]::SetEnvironmentVariable(TAOTOKEN_API_KEY, YOUR_TAOTOKEN_API_KEY, User)设置完记得重新开一个 PowerShell 窗口再执行codex --version和codex exec --help先确认入口没有变化再考虑做模型请求测试。settings.json 如果存在检查它是否和 config.toml 里的model_provider、base_url有冲突两处都写通道时以实际生效的那份为准不要留两份互相矛盾的配置。4. 用 TaoToken 统一 Key 收口并验证请求配置层理清后最后一步是把模型请求的 Key 和通道统一收口。TaoToken 的作用是提供一个统一的 API 入口让你在 Codex CLI、其他编码工具之间共用同一套 Key避免每个工具各配一份、互相覆盖。官网入口在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 地址是 https://taotoken.net/api 。先去控制台创建 Keyhttps://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewriteKey 管理页面在这里方便后续轮换和吊销https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite接入文档里有各工具的配置示例遇到字段名不确定时对照一下https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite配置写好后先用一条最小请求验证通道是否通。在 PowerShell 里直接测 API$headers { Authorization Bearer $env:TAOTOKEN_API_KEY Content-Type application/json } $body { model gpt-4o messages ({ role user; content ping }) } | ConvertTo-Json -Depth 5 Invoke-RestMethod -Uri https://taotoken.net/api/v1/chat/completions -Method Post -Headers $headers -Body $body如果返回里有正常的choices字段说明 Key 和通道没问题。接着再跑 Codex CLI 的最小任务先用 read-only 做无害检查codex exec --sandbox read-only --cd .\codes\codex-access-denied-demo 只读检查 src/server.js 的内容不要修改任何文件通过后再考虑 workspace-write。每次任务前后都运行git status --short做前后对比示例目录如果没有 Git 基线就用哈希或文件副本对比。没有看到真实返回内容之前不要写「Codex 已经修复」或「切换入口解决了问题」。如果你主要做长期编码或 Agent 任务可以了解 Coding Plan把额度集中管理https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite想先在网页里验证模型是否正常响应可以用模型对话页面https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite5. 本篇常见错排查错误一codex命令找不到或指向旧版本。用Get-Command codex -All和where.exe codex交叉确认显式用完整路径调用一次看版本是否和预期一致。多入口共存时优先固定一个入口不要靠 PATH 顺序碰运气。错误二改了 config.toml 但没生效。Codex 只在启动时读配置改完必须重开 PowerShell 窗口。另外检查CODEX_HOME是否被设到了别的目录导致你改的那份不是实际生效的那份。错误三环境变量在当前会话里没设上。$env:TAOTOKEN_API_KEY只对当前窗口有效用[Environment]::SetEnvironmentVariable写用户级变量后要新开窗口。验证时先echo $env:TAOTOKEN_API_KEY确认非空。错误四把codex sandbox和codex exec --sandbox混用。前者是单独跑一个受限命令后者是给代理任务选权限模式。报错信息里出现in-process app-server client时说明卡在初始化阶段和沙箱模式选择无关。错误五os error 5 出现在初始化阶段却去查测试断言。启动失败、模型请求失败、工具执行失败、代码测试失败是四种不同故障。先记录退出码和失败阶段再决定查哪一层。错误六把真实 Key 或配置原文贴出去排错。只提供脱敏后的命令、版本、错误阶段和退出码。Key 泄露后立即去 api-keys 页面吊销重发。6. 固定变量重试把结论停在可复核的地方排查这类问题最有效的方法不是一次改一堆东西而是固定变量、只替换一个。保留同一个示例项目、同一条任务说明、同一个沙箱级别只替换入口或配置中的一项每次都记录入口完整路径、codex --version、codex exec参数、退出码、是否产生文件变化、失败发生在哪个阶段。我试过在入口和配置都没对齐的情况下反复重跑结果只是把同一个 os error 5 复现了十几遍没有任何新信息。后来按「入口 → 配置 → 收口」的顺序逐层确认才把范围缩小到可复核的几条。你在 Windows 上遇到 Codex 启动错误时先运行Get-Command codex -All通常比直接重装更快知道自己到底在调用哪一份程序。如果后续重试成功把真实的终端输出补进来比任何推测都有价值。当前能确认的是多入口共存、版本可查、配置路径存在还没确认的是 os error 5 的唯一根因。把结论停在这里比填空更靠谱。