Windows app sandbox helpers are packaged under resources but launcher searches app/PATH

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #30047

Powered by Codex Action

Same here. And restarting Codex did not fix it. This happens in all modes (full access, custom, any...).

What I tested after the restart:
PowerShell command:
Write-Output 'ok'; Get-Location
from C:\somefolder\somefolder2

cmd.exe command:
echo ok && cd
from C:\somefolder\somefolder2

Both failed before the shell started, with the same Codex-side error:
Failed to create unified exec process: helper_unknown_error: setup refresh had errors

Same issue with CLI

I hit the same helper-discovery class of failure with the standalone Windows CLI install, and I think there is one more path shape involved: the standalone installer exposes codex.exe through a visible bin directory that is a Windows junction to the actual release bin directory.

Observed layout, with user-specific parts omitted:

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

%USERPROFILE%\.codex\packages\standalone\releases\0.142.5-x86_64-pc-windows-msvc\bin\codex.exe
%USERPROFILE%\.codex\packages\standalone\releases\0.142.5-x86_64-pc-windows-msvc\codex-resources\codex-windows-sandbox-setup.exe
%USERPROFILE%\.codex\packages\standalone\releases\0.142.5-x86_64-pc-windows-msvc\codex-resources\codex-command-runner.exe

In this layout the helpers are present, but lookup from the visible current_exe() path checks around:

%LOCALAPPDATA%\Programs\OpenAI\Codex\bin\...
%LOCALAPPDATA%\Programs\OpenAI\Codex\codex-resources\...

That misses the actual release codex-resources directory. If the executable path is canonicalized first, the lookup resolves through the junction to the real release bin, and ../codex-resources finds both helper binaries.

I prepared a candidate fix here:

https://github.com/starriet9/codex/tree/fix/windows-sandbox-helper-junction

Commit:

b6cee222c Fix Windows sandbox helper lookup through junctions

The patch keeps the existing literal lookup first, then falls back to the same lookup using dunce::canonicalize(exe) when the helper was not found. That should preserve existing layouts while fixing the standalone junction layout.

Local validation:

cargo fmt -p codex-windows-sandbox --check
git diff --check
cargo test -p codex-windows-sandbox helper_source_lookup

I also verified the path behavior with an isolated Windows junction probe: literal lookup from the visible junction path missed both helpers, while the canonicalized fallback found both helpers under the release codex-resources directory.

I am not opening a PR yet because docs/contributing.md says external PRs are by invitation only. If this direction matches the intended packaging/runtime behavior, I can open a focused PR from the branch above.

The following command fixes my install.ps1 installation.

TL;DR: This command identifies the most recent release directory (to which ~/.codex/packages/standalone/current is junction-linked) and creates hard links of <release>/codex-resources/{codex-command-runner.exe,codex-windows-sandbox-setup.exe} to the <release>/bin/ directory.

$standalonePath = Join-Path $env:USERPROFILE '.codex\packages\standalone'
$latestRelease = Get-ChildItem (Join-Path $standalonePath 'releases') -Directory | 
    Where-Object Name -Match '^\d+\.\d+\.\d+-' | 
    Sort-Object { [version](($_.Name -split '-')[0]) } -Descending | 
    Select-Object -First 1

$resourceExecutables = 'codex-command-runner.exe', 'codex-windows-sandbox-setup.exe'
$resourceExecutables | ForEach-Object {
    $sourcePath = Join-Path $latestRelease.FullName "codex-resources\$_"
    $linkPath = Join-Path $latestRelease.FullName "bin\$_"
    
    if (Test-Path $linkPath) { Remove-Item $linkPath -Force }
    New-Item -ItemType HardLink -Path $linkPath -Target $sourcePath | Out-Null
}

One liner:

$standalonePath=Join-Path $env:USERPROFILE '.codex\packages\standalone'; $latestRelease=Get-ChildItem (Join-Path $standalonePath 'releases') -Directory | Where-Object Name -Match '^\d+\.\d+\.\d+-' | Sort-Object {[version](($_.Name -split '-')[0])} -Descending | Select-Object -First 1; $resourceExecutables='codex-command-runner.exe','codex-windows-sandbox-setup.exe'; $resourceExecutables | ForEach-Object {$sourcePath=Join-Path $latestRelease.FullName "codex-resources\$_"; $linkPath=Join-Path $latestRelease.FullName "bin\$_"; if(Test-Path $linkPath){Remove-Item $linkPath -Force}; New-Item -ItemType HardLink -Path $linkPath -Target $sourcePath | Out-Null}

I can reproduce the same helper-discovery failure with the Microsoft Store Windows app, and it is intermittent within the same installed version.

Environment:

• Codex Windows app package: OpenAI.Codex_26.721.11231.0_x64__2p2nqsd0c76g0
• Windows native sandbox, workspace-write mode

Observed failure:

windows sandbox: orchestrator_helper_launch_failed:
setup refresh failed to launch helper:
helper=codex-windows-sandbox-setup.exe
...
error=program not found

The package contains both helpers at:

<package>\app\resources\codex-windows-sandbox-setup.exe
<package>\app\resources\codex-command-runner.exe

The most useful contrast is in the sandbox log on the same day:

• Successful refresh: spawning C:\Program Files\WindowsApps\OpenAI.Codex_26.721.11231.0_x64__2p2nqsd0c76g0\app\resources\codex-windows-sandbox-setup.exe, followed by setup binary completed.
• Failed refresh: spawning codex-windows-sandbox-setup.exe, followed by program not found.

So the executable is present and can be launched when the resolver uses its absolute packaged resource path; the intermittent failure appears to fall back to a bare filename that is not on PATH. I counted 131 instances of this specific launch failure in my sandbox logs from July 15–30 (24 in the latest seven days). I found no matching Microsoft Defender quarantine/block event.

This appears to be the same root cause as this issue, with the newer Store package and a particularly clear absolute-path vs bare-name comparison.