问题现象在 Windows 上使用 Codex 桌面版从 Microsoft Store 安装时所有 shell 命令均无法执行报错windows sandbox: CreateProcessWithLogonW failed: 1385错误码 1385 ERROR_LOGON_TYPE_NOT_GRANTED“用户未被授予此计算机上所请求的登录类型”。文件编辑apply_patch正常但whoami、dir等任何需要执行命令的操作全部失败。环境Windows 10 (10.0.19041)PowerShell 5.1Windows 加入企业域以下简称DOMAINCodex 桌面版从 Microsoft Store 安装域用户本地管理员排查过程第一步给账户加 SeBatchLogonRight错误信息指向CreateProcessWithLogonW这个 API 要求被登录用户拥有“作为批处理作业登录”SeBatchLogonRight权限。操作方式二选一secpol.msc→ 本地策略 → 用户权限分配 → “作为批处理作业登录” → 添加当前用户或用secedit命令行修改修改后用secedit /export确认策略里确实包含了当前用户的 SID。结果注销重新登录后仍然报 1385。第二步排查 Deny 权限Windows 用户权限分配中Deny 优先于 Allow。检查策略里是否存在SeDenyBatchLogonRight$cfg $env:TEMP\check.cfg secedit /export /cfg $cfg /quiet Select-String -Path $cfg -Pattern SeDeny.*Logon发现存在SeDenyBatchLogonRight指向另一个域组的 SID。但用whoami /groups确认当前用户不在该组中。进一步检查所有 SeDeny 条目SeDenyNetworkLogonRight *S-1-5-21-...-xxx (某限制组) SeDenyBatchLogonRight *S-1-5-21-...-xxx (某限制组) SeDenyInteractiveLogonRight *S-1-5-21-...-xxx SeDenyRemoteInteractiveLogonRight *S-1-5-21-...-xxx当前用户不在这些组里Deny 不应该生效。排除此方向。第三步确认 OS 层面 batch logon 是否可用直接调用 Win32LogonUserAPI用 Batch 登录类型type 4测试$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。进一步测试所有 5 种登录类型全部成功Interactive (type 2): SUCCESS Network (type 3): SUCCESS Batch (type 4): SUCCESS NetworkCleartext (type 8): SUCCESS NewCredentials (type 9): SUCCESS结论OS 层面权限完全正常问题不在用户权限分配。第四步确认 seclogon 服务CreateProcessWithLogonW依赖 Secondary Logon 服务seclogonGet-Service seclogon结果服务状态 Running启动类型 Manual。排除此方向。第五步从 Codex 二进制提取 sandbox 模式既然 OS 层面一切正常问题出在 Codex 的沙箱实现。从 Codex 的codex.exe二进制中搜索 sandbox 相关字符串$exe C:\Program Files\WindowsApps\OpenAI.Codex_*\app\resources\codex.exe $text [System.IO.File]::ReadAllText($exe, [System.Text.Encoding]::GetEncoding(iso-8859-1)) # 搜索 sandbox 附近的字符串 $text.Substring($text.IndexOf(elevated) - 40, 120)在sandbox.rs代码段附近发现两个模式值elevated和unelevated。同时发现二进制同时导入了两个 Windows APICreateProcessWithLogonW ← elevated 模式使用报 1385 CreateProcessAsUserW ← unelevated 模式可能使用第六步切换 sandbox 模式修改~/.codex/config.toml# 修改前报 1385 [windows] sandbox elevated 修改后正常 [windows] sandbox unelevated完全退出 Codex重新打开whoami成功返回用户名所有 shell 命令恢复正常。问题解决。根因分析层面结论用户权限SeBatchLogonRight正常OS 层面 LogonUser(batch) 测试通过Deny 权限SeDenyBatchLogonRight存在但当前用户不在 deny 组中seclogon 服务正常运行所有 5 种登录类型全部成功Codex sandbox elevated用CreateProcessWithLogonW创建沙箱进程在域环境 Store 应用 token 上下文下报 1385Codex sandbox unelevated用不同方式创建进程CreateProcessAsUserW或CreateProcess绕过 1385CreateProcessWithLogonW和LogonUser的关键区别LogonUser只需要被登录用户的权限SeBatchLogonRight调用方不需要特殊权限CreateProcessWithLogonW通过 seclogon 服务创建进程调用方进程的 token 上下文会影响调用结果Codex 作为 Store 应用即使以管理员身份运行其进程 token 可能经过过滤导致CreateProcessWithLogonW失败最终解决方案编辑C:\Users\你的用户名\.codex\config.toml将[windows] sandbox elevated改为[windows] sandbox unelevated保存后完全退出 Codex任务管理器确认无残留进程重新打开即可。补充说明如果你的 config.toml 里没有 [windows] 段手动添加即可[windows] sandbox unelevatedelevated 和 unelevated 的区别elevated通过CreateProcessWithLogonW创建提升权限的沙箱进程隔离性更强但对调用方 token 要求更高unelevated通过其他方式创建进程不依赖CreateProcessWithLogonW兼容性更好适用场景这个问题主要出现在以下条件同时满足时Windows 加入企业域Codex 从 Microsoft Store 安装域策略对用户 token 有一定限制如果你遇到同样的 1385 错误直接尝试切换到unelevated模式大概率能解决。如果不行再按本文的排查步骤逐步确认 OS 层面权限是否正常。排查命令速查# 1. 检查 SeBatchLogonRight $cfg $env:TEMP\check.cfg secedit /export /cfg $cfg /quiet Select-String -Path $cfg -Pattern SeBatchLogonRight 2. 检查 SeDeny 权限 Select-String -Path $cfg -Pattern SeDeny.*Logon 3. 确认当前用户 SID whoami /user 4. 确认所属组 whoami /groups 5. 检查 seclogon 服务 Get-Service seclogon 6. 直接测试 LogonUser (Batch) 见上方第三步的 PowerShell 脚本 7. 从 Codex 二进制搜索 sandbox 模式 $exe C:\Program Files\WindowsApps\OpenAI.Codex_*\app\resources\codex.exe $text [System.IO.File]::ReadAllText($exe, [System.Text.Encoding]::GetEncoding(iso-8859-1)) $text.Substring($text.IndexOf(elevated) - 40, 120) Codex 桌面版 Windows 沙箱 CreateProcessWithLogonW 报错 1385 的排查与解决
问题现象在 Windows 上使用 Codex 桌面版从 Microsoft Store 安装时所有 shell 命令均无法执行报错windows sandbox: CreateProcessWithLogonW failed: 1385错误码 1385 ERROR_LOGON_TYPE_NOT_GRANTED“用户未被授予此计算机上所请求的登录类型”。文件编辑apply_patch正常但whoami、dir等任何需要执行命令的操作全部失败。环境Windows 10 (10.0.19041)PowerShell 5.1Windows 加入企业域以下简称DOMAINCodex 桌面版从 Microsoft Store 安装域用户本地管理员排查过程第一步给账户加 SeBatchLogonRight错误信息指向CreateProcessWithLogonW这个 API 要求被登录用户拥有“作为批处理作业登录”SeBatchLogonRight权限。操作方式二选一secpol.msc→ 本地策略 → 用户权限分配 → “作为批处理作业登录” → 添加当前用户或用secedit命令行修改修改后用secedit /export确认策略里确实包含了当前用户的 SID。结果注销重新登录后仍然报 1385。第二步排查 Deny 权限Windows 用户权限分配中Deny 优先于 Allow。检查策略里是否存在SeDenyBatchLogonRight$cfg $env:TEMP\check.cfg secedit /export /cfg $cfg /quiet Select-String -Path $cfg -Pattern SeDeny.*Logon发现存在SeDenyBatchLogonRight指向另一个域组的 SID。但用whoami /groups确认当前用户不在该组中。进一步检查所有 SeDeny 条目SeDenyNetworkLogonRight *S-1-5-21-...-xxx (某限制组) SeDenyBatchLogonRight *S-1-5-21-...-xxx (某限制组) SeDenyInteractiveLogonRight *S-1-5-21-...-xxx SeDenyRemoteInteractiveLogonRight *S-1-5-21-...-xxx当前用户不在这些组里Deny 不应该生效。排除此方向。第三步确认 OS 层面 batch logon 是否可用直接调用 Win32LogonUserAPI用 Batch 登录类型type 4测试$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。进一步测试所有 5 种登录类型全部成功Interactive (type 2): SUCCESS Network (type 3): SUCCESS Batch (type 4): SUCCESS NetworkCleartext (type 8): SUCCESS NewCredentials (type 9): SUCCESS结论OS 层面权限完全正常问题不在用户权限分配。第四步确认 seclogon 服务CreateProcessWithLogonW依赖 Secondary Logon 服务seclogonGet-Service seclogon结果服务状态 Running启动类型 Manual。排除此方向。第五步从 Codex 二进制提取 sandbox 模式既然 OS 层面一切正常问题出在 Codex 的沙箱实现。从 Codex 的codex.exe二进制中搜索 sandbox 相关字符串$exe C:\Program Files\WindowsApps\OpenAI.Codex_*\app\resources\codex.exe $text [System.IO.File]::ReadAllText($exe, [System.Text.Encoding]::GetEncoding(iso-8859-1)) # 搜索 sandbox 附近的字符串 $text.Substring($text.IndexOf(elevated) - 40, 120)在sandbox.rs代码段附近发现两个模式值elevated和unelevated。同时发现二进制同时导入了两个 Windows APICreateProcessWithLogonW ← elevated 模式使用报 1385 CreateProcessAsUserW ← unelevated 模式可能使用第六步切换 sandbox 模式修改~/.codex/config.toml# 修改前报 1385 [windows] sandbox elevated 修改后正常 [windows] sandbox unelevated完全退出 Codex重新打开whoami成功返回用户名所有 shell 命令恢复正常。问题解决。根因分析层面结论用户权限SeBatchLogonRight正常OS 层面 LogonUser(batch) 测试通过Deny 权限SeDenyBatchLogonRight存在但当前用户不在 deny 组中seclogon 服务正常运行所有 5 种登录类型全部成功Codex sandbox elevated用CreateProcessWithLogonW创建沙箱进程在域环境 Store 应用 token 上下文下报 1385Codex sandbox unelevated用不同方式创建进程CreateProcessAsUserW或CreateProcess绕过 1385CreateProcessWithLogonW和LogonUser的关键区别LogonUser只需要被登录用户的权限SeBatchLogonRight调用方不需要特殊权限CreateProcessWithLogonW通过 seclogon 服务创建进程调用方进程的 token 上下文会影响调用结果Codex 作为 Store 应用即使以管理员身份运行其进程 token 可能经过过滤导致CreateProcessWithLogonW失败最终解决方案编辑C:\Users\你的用户名\.codex\config.toml将[windows] sandbox elevated改为[windows] sandbox unelevated保存后完全退出 Codex任务管理器确认无残留进程重新打开即可。补充说明如果你的 config.toml 里没有 [windows] 段手动添加即可[windows] sandbox unelevatedelevated 和 unelevated 的区别elevated通过CreateProcessWithLogonW创建提升权限的沙箱进程隔离性更强但对调用方 token 要求更高unelevated通过其他方式创建进程不依赖CreateProcessWithLogonW兼容性更好适用场景这个问题主要出现在以下条件同时满足时Windows 加入企业域Codex 从 Microsoft Store 安装域策略对用户 token 有一定限制如果你遇到同样的 1385 错误直接尝试切换到unelevated模式大概率能解决。如果不行再按本文的排查步骤逐步确认 OS 层面权限是否正常。排查命令速查# 1. 检查 SeBatchLogonRight $cfg $env:TEMP\check.cfg secedit /export /cfg $cfg /quiet Select-String -Path $cfg -Pattern SeBatchLogonRight 2. 检查 SeDeny 权限 Select-String -Path $cfg -Pattern SeDeny.*Logon 3. 确认当前用户 SID whoami /user 4. 确认所属组 whoami /groups 5. 检查 seclogon 服务 Get-Service seclogon 6. 直接测试 LogonUser (Batch) 见上方第三步的 PowerShell 脚本 7. 从 Codex 二进制搜索 sandbox 模式 $exe C:\Program Files\WindowsApps\OpenAI.Codex_*\app\resources\codex.exe $text [System.IO.File]::ReadAllText($exe, [System.Text.Encoding]::GetEncoding(iso-8859-1)) $text.Substring($text.IndexOf(elevated) - 40, 120)