Windows sandbox fails with standalone CLI despite valid junction install layout

What version of Codex CLI is running?

codex-cli 0.136.0

What subscription do you have?

gpt plus

Which model were you using?

_No response_

What platform is your computer?

Microsoft Windows 11 专业版 10.0.26200 64 位

What terminal emulator and version are you using (if applicable)?

PowerShell / Windows Terminal

Codex doctor report

What issue are you seeing?

On Windows, the Codex standalone CLI installation appears structurally correct and codex doctor reports the install as consistent. However, codex sandbox fails in multiple ways depending on which entrypoint is used and whether the shell is elevated.

The core symptoms are:

1. When launching via the visible PATH entrypoint:

%LOCALAPPDATA%\Programs\OpenAI\Codex\bin\codex.exe
sandbox setup/runner resolution can fail even though the visible bin directory is a junction to the standalone current\bin directory.

1. When launching the standalone package bin\codex.exe directly and ensuring codex-resources is on PATH, sandbox works only from an elevated Administrator shell. From a normal shell it fails with os error 740 / spawn setup refresh.

This looks like a Windows standalone CLI sandbox resource-resolution and/or elevation-flow issue rather than an incomplete user installation.

What steps can reproduce the bug?

Case 1: Visible PATH entrypoint, normal PowerShell
$codex = "$env:LOCALAPPDATA\Programs\OpenAI\Codex\bin\codex.exe"

& $codex --version
& $codex doctor --summary --ascii
& $codex sandbox powershell.exe -NoProfile -Command "[Console]::OutputEncoding=[Text.Encoding]::UTF8; Get-Date -Format 'yyyy-MM-dd HH:mm:ss'"
Actual result:

windows sandbox failed: spawn setup refresh
Sandbox log:

setup refresh: spawning codex-windows-sandbox-setup.exe (cwd=C:\Users\clint, payload_len=3548)
setup refresh: failed to spawn codex-windows-sandbox-setup.exe: program not found
Case 2: Visible PATH entrypoint with standalone resources added to PATH
$standalone = "$env:USERPROFILE\.codex\packages\standalone\releases\0.136.0-x86_64-pc-windows-msvc"
$env:PATH = "$standalone\codex-resources;$standalone\codex-path;$env:PATH"

$codex = "$env:LOCALAPPDATA\Programs\OpenAI\Codex\bin\codex.exe"
& $codex sandbox powershell.exe -NoProfile -Command "[Console]::OutputEncoding=[Text.Encoding]::UTF8; Get-Date -Format 'yyyy-MM-dd HH:mm:ss'"
Normal PowerShell result:

windows sandbox failed: spawn setup refresh
Sandbox log:

setup refresh: spawning codex-windows-sandbox-setup.exe (cwd=C:\Users\clint, payload_len=3548)
setup refresh: failed to spawn codex-windows-sandbox-setup.exe: 请求的操作需要提升。 (os error 740)
Case 3: Visible PATH entrypoint in Administrator PowerShell
With the same PATH adjustment, setup may complete, but command runner resolution fails.

Sandbox log:

setup refresh: processed 0 write roots (read roots delegated); errors=[]
setup binary completed
helper copy failed for command-runner: helper not found next to current executable or under codex-resources: C:\Users\clint\AppData\Local\Programs\OpenAI\Codex\bin\codex.exe; falling back to legacy path codex-command-runner.exe
Observed result:

windows sandbox failed: CreateProcessWithLogonW failed: 2
Case 4: Direct standalone package bin\codex.exe, normal PowerShell
$pkg = "$env:USERPROFILE\.codex\packages\standalone\current"
$codex = "$pkg\bin\codex.exe"
$env:PATH = "$pkg\codex-resources;$pkg\codex-path;$env:PATH"

& $codex sandbox powershell.exe -NoProfile -Command "[Console]::OutputEncoding=[Text.Encoding]::UTF8; Get-Date -Format 'yyyy-MM-dd HH:mm:ss'"
Actual result:

windows sandbox failed: spawn setup refresh
Sandbox log:

setup refresh: failed to spawn C:\Users\clint\.codex\packages\standalone\releases\0.136.0-x86_64-pc-windows-msvc\codex-resources\codex-windows-sandbox-setup.exe: 请求的操作需要提升。 (os error 740)
Case 5: Direct standalone package bin\codex.exe, Administrator PowerShell
$pkg = "$env:USERPROFILE\.codex\packages\standalone\current"
$codex = "$pkg\bin\codex.exe"
$env:PATH = "$pkg\codex-resources;$pkg\codex-path;$env:PATH"

& $codex sandbox powershell.exe -NoProfile -Command "[Console]::OutputEncoding=[Text.Encoding]::UTF8; Get-Date -Format 'yyyy-MM-dd HH:mm:ss'"
Actual result:

2026-06-02 17:20:01
Sandbox log:

setup refresh: spawning C:\Users\clint\.codex\packages\standalone\releases\0.136.0-x86_64-pc-windows-msvc\codex-resources\codex-windows-sandbox-setup.exe
setup refresh: processed 0 write roots (read roots delegated); errors=[]
setup binary completed
helper copy: validating command-runner source=C:\Users\clint\.codex\packages\standalone\releases\0.136.0-x86_64-pc-windows-msvc\codex-resources\codex-command-runner.exe destination=C:\Users\clint\.codex\.sandbox-bin\codex-command-runner-0.136.0.exe
helper launch resolution: using copied command-runner path C:\Users\clint\.codex\.sandbox-bin\codex-command-runner-0.136.0.exe

What is the expected behavior?

Expected behavior
Given that the installation layout is valid and codex doctor resolves the standalone package paths correctly, I would expect:

codex sandbox ... launched via the visible PATH entrypoint to correctly resolve:

%USERPROFILE%\.codex\packages\standalone\current\codex-resources
%USERPROFILE%\.codex\packages\standalone\current\codex-path
even when the visible bin directory is a junction.

If sandbox setup requires elevation, the CLI should either:

successfully initiate the elevation flow from a normal shell, or
provide a clearer error explaining that Administrator privileges are required for this operation.
The visible entrypoint should behave consistently with directly launching:

%USERPROFILE%\.codex\packages\standalone\current\bin\codex.exe
Actual behavior
The visible entrypoint can fail to resolve sandbox setup/helper resources.
Adding codex-resources to PATH changes the error from program not found to os error 740.
Running from Administrator with the visible entrypoint can still fail to resolve codex-command-runner.exe.
Directly running the standalone package bin\codex.exe works only from Administrator PowerShell.

Additional information

I created a wrapper script:

@echo off
set "PKG=%USERPROFILE%\.codex\packages\standalone\current"
set "PATH=%PKG%\codex-resources;%PKG%\codex-path;%PATH%"
"%PKG%\bin\codex.exe" %*
exit /b %ERRORLEVEL%
Running this wrapper from an Administrator shell allows sandbox commands to work.

However, this is not ideal for tools such as Obsidian plugins that need to call Codex CLI normally, because it requires the entire calling application to be launched as Administrator if sandbox mode is needed.

Why this looks like a CLI/sandbox bug
The install layout appears normal:

%LOCALAPPDATA%\Programs\OpenAI\Codex\bin
-> %USERPROFILE%\.codex\packages\standalone\current\bin

%USERPROFILE%\.codex\packages\standalone\current
-> %USERPROFILE%\.codex\packages\standalone\releases\0.136.0-x86_64-pc-windows-msvc
The package contains the expected resources, and doctor reports the install as consistent.

The failure seems to occur at runtime in either:

resolving codex-resources / codex-command-runner.exe when launched via the visible bin junction, and/or
handling sandbox setup elevation from a normal non-admin shell.
Could you please confirm whether the Windows standalone CLI is expected to support sandbox mode from a non-admin shell, and whether resource resolution through the visible bin junction is intended to work?