Original Summary

github.com/openai/codex [Windows] Regression in CLI 0.155.0: elevated sandbox initialization fails during runtime path validation; 0.154.0 works 已打开 08:06AM - 18 Sep 26 UTC TomatoFiredEggs bug windows-os sandbox CLI app ### What version of the Codex App are you using (From “About Codex” dialog)? CL … I 0.155.0 ### What subscription do you have? pro ### What platform is your computer? OS: Windows 10 Pro 22H2, build 19045.6456, x64 Affected Codex CLI version: 0.155.0 Working Codex CLI version: 0.154.0 Installation method: npm global installation (@openai/codex) Shells tested: PowerShell 7.6.6, PowerShell 7.5.11, and cmd.exe Windows sandbox implementation: elevated Sandbox mode: workspace-write Approval policy: on-request Windows LongPathsEnabled: 1 ### What issue are you seeing? After updating Codex CLI to 0.155.0 on Windows, sandboxed commands consistently fail during elevated sandbox initialization, before the requested command starts. Even a simple read-only command such as Get-Date cannot run. The error returned is: ``text Failed to create unified exec process: helper_unknown_error: setup refresh had errors ` The sandbox log identifies a failure while validating read/execute access to a directory inside Codex's own cua_node runtime dependency cache: `text runtime read/execute validation failed: validate runtime read/execute access on <runtime-cache-path>: CreateFileW failed for <runtime-cache-path> setup error: setup refresh had errors ` The affected path is shown below with the Windows username redacted. The original, unredacted path is 291 characters long: `text C:\Users\<USER>\AppData\Local\OpenAI\Codex\runtimes\cua_node\b58ca2eaa616c2da\bin\node_modules\@oai\sky\dist\js-dependency-cache\shared-v1\applied-bk-agent-openai-js\pnpm-store\v11\links\@rollup\plugin- typescript\12.1.2\bf978194e78e4126a616bfdc5a9fea913609f48ddc1a68ce028d4322c58982dd ` This directory exists and is a regular directory, not a symbolic link. codex doctor --summary reports: `text ✓ install consistent ✓ config loaded ✗ sandbox elevated Windows sandbox provisioning recorded a structured failure ` Downgrading the npm-installed CLI to 0.154.0 restored sandboxed command execution and workspace file read/write operations while retaining windows.sandbox = "elevated". ### What steps can reproduce the bug? Observed on my existing Windows installation: 1. Install Codex CLI 0.155.0: `powershell npm install -g @openai/codex@0.155.0 ` 2. Use the following configuration: `toml sandbox_mode = "workspace-write" approval_policy = "on-request" [windows] sandbox = "elevated" ` 3. Restart Codex and request a simple sandboxed command, such as Get-Date. 4. Observe that sandbox initialization fails with: `text helper_unknown_error: setup refresh had errors ` 5. Exit Codex and downgrade: `powershell npm install -g @openai/codex@0.154.0 ` 6. Restart Codex with the same sandbox configuration and repeat the test. Result: On 0.154.0, sandboxed commands succeed. Creating, reading, and removing a temporary file inside the workspace also succeeds. This has been reproduced on my existing installation containing the runtime cache described above; I have not tested a clean Windows installation. ### What is the expected behavior? _No response_ ### Additional information Troubleshooting performed: - Restarted Codex and rebooted Windows: no improvement. - Reinstalled CLI 0.155.0: no improvement. - Replaced PowerShell 7.6.6 with 7.5.11: no improvement. - Tested cmd.exe instead of PowerShell: the same sandbox initialization failure. - Commands outside the sandbox run successfully. - Downgraded to CLI 0.154.0: sandbox command execution and workspace read/write recovered without switching to unelevated. Possible long-path handling issue — not yet confirmed as the root cause: - The original failing directory path is 291 characters long. - Windows LongPathsEnabled is already set to 1. - A read-only CreateFileW probe under my current Windows user failed for the ordinary path with Win32 error 3. - The same probe succeeded when the path was prefixed with \\?\, without changing permissions. - The inspected directory and parent ACLs contain allow entries for CodexSandboxUsers; no explicit deny entries were found in those inspected ACLs. - The embedded application manifest inspected in codex-windows-sandbox-setup.exe did not contain a longPathAware` declaration. The path-opening probe was performed under my current user, not the sandbox account, so it does not fully rule out sandbox-token or effective-permission issues. The confirmed observation is the version-dependent behavior: 0.155.0 fails on this machine, while 0.154.0 works. Long-path handling during runtime validation is a suspected trigger, not a confirmed implementation-level diagnosis. 目前需要降级0.154.0来解决问题 1 个帖子 - 1 位参与者 阅读完整话题

  • 情报分类：商业与市场研究
  • 分类依据：内容涉及商业、投资或市场动态
  • 信息来源：服务器 / LINUX DO - 最新话题
  • 发布时间：2026/9/22 16:45:27