1. 先看清 1385 到底卡在哪一层Codex 桌面版在 Windows 上跑 shell 命令时如果弹出windows sandbox: CreateProcessWithLogonW failed: 1385说明沙箱进程创建这一步被系统拒绝了。1385 对应ERROR_LOGON_TYPE_NOT_GRANTED直译是“未授予用户在此计算机上的请求登录类型”。很多人第一反应是去加SeBatchLogonRight但加完注销重登还是报同样的错于是开始怀疑人生。这个报错的迷惑性在于文件编辑apply_patch完全正常只有whoami、dir这类需要真正起进程的操作全挂。也就是说 Codex 本体没坏坏的是它调起子进程的那条路径。Codex 桌面版从 Microsoft Store 安装、机器又加入了企业域时进程 token 会经过一层过滤CreateProcessWithLogonW这种依赖 Secondary Logon 服务、且对调用方 token 上下文敏感的方式就容易翻车。这篇面向的是本地 AI 工具接入统一 Key/API 通道的开发者你已经在用 TaoToken 这类统一通道管理模型调用Codex 只是其中一个客户端结果被 Windows 沙箱拦在门外。下面按“先确认 OS 权限正常 → 再定位 Codex 沙箱模式 → 改配置验证”的顺序走最后给出可复制的config.toml与settings.json骨架以及一套权限检查清单。核心结论先放这多数情况下把sandbox从elevated切到unelevated就能消掉 1385但前提是你得先证明 OS 层面没问题否则就是瞎改。2. TaoToken 统一 Key 通道的前置准备在动 Windows 权限之前先把模型调用这条链路理顺避免把“沙箱报错”和“Key 没配好”混在一起排查。TaoToken 的作用是把多家模型的调用收敛到一个统一入口Codex、Claude Code 这类客户端只需要认一个 base URL 和一个 Key不用每个工具单独维护一套凭证。你需要准备的东西一个可用的 API Key在控制台的 API Keys 页面创建https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite统一接入地址https://taotoken.net/api 这个地址不加 UTM直接填进配置想先验证模型通不通可以用模型对话页面发一条测试消息https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite长期跑编码或 Agent 任务建议看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite注意先把 Key 通道验证通过再去折腾沙箱。否则你改完sandbox模式命令能跑了结果模型请求 401又得回头查一遍白白多花时间。Codex 桌面版的配置分两块一块是模型/通道相关的config.toml一块是桌面端行为相关的settings.json。两者位置不同别搞混。下面第 3 节给骨架。3. 可复制的 config.toml 与 settings.json 骨架Codex 的用户级配置目录在C:\Users\你的用户名\.codex\。先确认这个目录存在不存在就手动建。config.toml负责模型通道和 Windows 沙箱模式settings.json负责桌面端的一些运行参数。先看config.toml的完整骨架重点是[windows]段# C:\Users\你的用户名\.codex\config.toml # 模型通道统一走 TaoToken model gpt-5-codex model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY # Windows 沙箱模式报 1385 时从 elevated 改为 unelevated [windows] sandbox unelevated如果你原来的config.toml里根本没有[windows]段直接手动补上这两行即可不用管其他段。sandbox只有两个有效值elevated和unelevated。elevated走CreateProcessWithLogonW创建提升权限的沙箱进程隔离性更强但对调用方进程 token 要求高域环境 Store 应用 token 过滤下容易返回 1385。unelevated换用不依赖CreateProcessWithLogonW的方式创建进程兼容性更好代价是隔离强度略降。再看settings.json骨架它一般和config.toml同目录{ sandbox: { mode: unelevated, allowNetwork: true }, shell: { defaultShell: powershell, timeoutMs: 120000 }, telemetry: { enabled: false } }settings.json里的sandbox.mode和config.toml里的[windows] sandbox要保持一致避免一个说 elevated 一个说 unelevated行为不确定。allowNetwork按需开如果你只是本地跑命令可以设 false 收紧一点。环境变量TAOTOKEN_API_KEY建议在系统级或用户级设置别写死在配置文件里# 用户级环境变量设置后需重开终端 [Environment]::SetEnvironmentVariable(TAOTOKEN_API_KEY, 你的Key, User)设置完用echo $env:TAOTOKEN_API_KEY确认能读到。读不到就重开一个 PowerShell 窗口环境变量不会在已开的会话里自动刷新。4. 权限与用户权限分配检查清单改配置之前先按这份清单确认 OS 层面确实没问题。这一步的意义是如果 OS 权限本身就缺那你切unelevated只是绕过根因还在。清单按顺序执行每步都有预期结果。第一步导出当前安全策略并检查SeBatchLogonRight$cfg $env:TEMP\check.cfg secedit /export /cfg $cfg /quiet Select-String -Path $cfg -Pattern SeBatchLogonRight预期输出里应包含当前用户的 SID。没有的话用secpol.msc→ 本地策略 → 用户权限分配 → “作为批处理作业登录” → 添加当前用户。第二步检查所有 Deny 条目。Deny 优先于 Allow这是 Windows 权限的铁律Select-String -Path $cfg -Pattern SeDeny.*Logon预期可能看到SeDenyBatchLogonRight、SeDenyNetworkLogonRight等指向某些组。关键是用whoami /groups确认当前用户不在这些组里。不在Deny 就不生效可以排除。第三步确认当前用户 SID 和所属组whoami /user whoami /groups把whoami /user输出的 SID 和第一步策略里的 SID 对一下确认是同一个账户。第四步确认 Secondary Logon 服务在跑。CreateProcessWithLogonW依赖它Get-Service seclogon预期Status为RunningStartType为Manual或Automatic。没跑就Start-Service seclogon。第五步直接用LogonUserAPI 测 Batch 登录类型type 4。这一步是分水岭如果这里成功说明 OS 权限完全正常问题一定在 Codex 沙箱实现$cred Get-Credential $env:USERDOMAIN\$env:USERNAME Add-Type using System; using System.Runtime.InteropServices; public class Logon { [DllImport(advapi32.dll, SetLastError true)] public static extern bool LogonUser(string lpszUsername, string lpszDomain, string lpszPassword, int dwLogonType, int dwLogonProvider, out IntPtr phToken); } $token [IntPtr]::Zero $pw [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($cred.Password) $pwPlain [System.Runtime.InteropServices.Marshal]::PtrToStringBSTR($pw) $user $cred.UserName.Split(\) $result [Logon]::LogonUser($user[1], $user[0], $pwPlain, 4, 0, [ref]$token) $err [System.Runtime.InteropServices.Marshal]::GetLastWin32Error() if ($result) { Write-Host Batch logon SUCCESS } else { Write-Host FAILED - error $err }预期输出Batch logon SUCCESS。如果这里就失败那先解决 OS 权限别急着改 Codex 配置。把上面五步的结果填进这张对照表心里就有数了检查项命令/位置正常表现异常处理SeBatchLogonRightsecedit 导出后 Select-String含当前用户 SIDsecpol.msc 添加Deny 权限Select-String SeDeny.*Logon当前用户不在 deny 组确认组成员关系seclogon 服务Get-Service seclogonRunningStart-ServiceLogonUser batch上面 PowerShell 脚本SUCCESS查 OS 权限沙箱模式config.toml [windows]unelevated改配置5. 复现与验证从 1385 到命令正常返回先复现确认你遇到的确实是这个错。把config.toml的[windows] sandbox设回elevated完全退出 Codex任务管理器里确认没有残留进程重开随便跑一条whoami。预期看到windows sandbox: CreateProcessWithLogonW failed: 1385复现成功后改配置。把[windows] sandbox改成unelevated同时确认settings.json里sandbox.mode也是unelevated。保存。关键动作完全退出 Codex。不是关窗口是去任务管理器结束所有 Codex 相关进程。Store 应用有时会驻留后台不彻底退出的话配置不生效你会以为改了没用。重开 Codex再跑whoami。预期返回当前用户名比如domain\yourname。再跑dir、git status之类应该都正常。到这里 1385 消除。如果切了unelevated还报 1385说明问题不在沙箱模式回到第 4 节把 OS 权限再核一遍尤其是LogonUser那步是否真的 SUCCESS。还有一种情况config.toml里同时存在多个[windows]段TOML 解析时后者覆盖前者你以为改了其实没生效。用编辑器搜一下[windows]出现几次。验证模型通道是否也通可以在 Codex 里发一条简单请求或者直接用模型对话页面测https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite 。命令能跑 模型能回才算整条链路打通。6. 本篇常见错排查错误一改了 config.toml 但没退出 Codex。最常见。Store 应用进程驻留配置在启动时读取不重启不生效。养成习惯改配置 → 任务管理器确认无残留 → 重开。错误二只加了 SeBatchLogonRight 就以为能解决。如果LogonUserbatch 测试已经 SUCCESS再加这个权限是无效操作因为 OS 层面本来就没缺。1385 来自CreateProcessWithLogonW的调用方 token 上下文不是被登录用户的权限。错误三把settings.json和config.toml的 sandbox 模式设成不一致。一个 elevated 一个 unelevated行为取决于哪个先被读排查时会被误导。统一成 unelevated。错误四环境变量TAOTOKEN_API_KEY没生效。在已开的终端里设了变量但 Codex 是从系统环境读的读不到就报鉴权失败。用[Environment]::SetEnvironmentVariable(..., User)设用户级然后重开终端和 Codex。错误五以为unelevated是降级不安全。它只是换了一种创建进程的方式不依赖CreateProcessWithLogonW隔离强度略降但仍在沙箱内。对本地开发场景够用。真要强隔离得先解决域环境下的 token 过滤问题那是另一条路。错误六config.toml里base_url写成了带路径的完整 URL。统一接入地址就是https://taotoken.net/api不要自己拼/v1/chat/completions之类客户端会自己处理路径。排查命令速查存下来备用# 检查 SeBatchLogonRight $cfg $env:TEMP\check.cfg secedit /export /cfg $cfg /quiet Select-String -Path $cfg -Pattern SeBatchLogonRight # 检查 Deny 权限 Select-String -Path $cfg -Pattern SeDeny.*Logon # 当前用户 SID 与组 whoami /user whoami /groups # seclogon 服务 Get-Service seclogon # 确认 Codex 进程是否残留 Get-Process | Where-Object { $_.ProcessName -like *codex* }最后一步Get-Process很实用改完配置先跑它有输出就说明没退干净先Stop-Process再重开。这个习惯能省掉一半“改了没用”的困惑。如果你还在搭统一 Key 通道先把 API Key 建好https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite 接入细节看文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite 。长期跑编码任务的话Coding Plan 那条线更省心https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite 。