Windows VPS: workspace dependencies remain “Not installed”; .sandbox-bin stays empty after reinstall

[Kysta]

What version of the Codex App are you using?

Codex installed fresh from the Microsoft Store on May 9, 2026. Store page publisher: OpenAI.

The exact app version was not captured from the About dialog yet, but the current user config contains:

model = "gpt-5.5"
model_reasoning_effort = "medium"

[windows]
sandbox = "elevated"

What subscription do you have?

ChatGPT account connected successfully. Subscription tier not included here.

What platform is your computer?

Windows 11 Enterprise on a VPS, x64.

Installed prerequisites verified before installing Codex:

• Microsoft Edge WebView2 Runtime: 148.0.3967.54
• Microsoft Visual C++ Redistributable x64: 14.50.35719.0
• Git for Windows: 2.54.0.windows.1
• winget: v1.28.240

What issue are you seeing?

Codex starts successfully and the account login works, but the workspace dependency installer never completes.

In Settings > Configuration > Workspace dependencies:

• Current version remains Not installed / Non installée.
• Clicking Diagnose shows the banner: “Les dépendances Codex doivent peut-être être réparées. Envoyez un message via /feedback si le problème persiste.”
• Clicking Reinstall briefly changes the status to “Preparing your workspace” / “Préparation de votre espace de travail”, then returns to Not installed.

Feedback was also submitted from the app with correlation ID:

019e0c23-d3cb-7092-a299-ad2116418965

Local observations

After the failed dependency reinstall:

• C:\Users\Admin\.codex\.sandbox exists.
• C:\Users\Admin\.codex\.sandbox\setup_marker.json exists.
• C:\Users\Admin\.codex\.sandbox\sandbox.log indicates the Windows sandbox setup succeeded.
• C:\Users\Admin\.codex\.sandbox-bin remains empty.
• No stuck Codex/Node/Python process was found during the diagnostic.

Relevant sandbox.log excerpts:

ensuring sandbox users offline=CodexSandboxOffline online=CodexSandboxOnline
WFP setup succeeded for CodexSandboxOffline with 12 installed filters
setup binary completed
read-acl-only mode: applying read ACLs
granting read ACE to C:\Users\Admin\.cache for sandbox users
granting read ACE to C:\Users\Admin\.codex for sandbox users
granting read ACE to C:\Users\Admin\.gitconfig for sandbox users
granting read ACE to C:\Users\Admin\AppData for sandbox users
read ACL run completed

Windows Event Log signals

Recent Windows Error Reporting entries include:

AppxDeploymentFailureBlue
P1: 80073CF3

and:

MicrosoftEdgeUpdate.exe
InstallError|webview
0x80040902

WebView2 was then installed/repaired successfully via winget and is currently listed as installed, but the Codex workspace dependencies still remain Not installed.

Steps to reproduce

1. Start from a cleaned Windows 11 Enterprise VPS.
2. Install/verify WebView2 Runtime, VC++ Redistributable x64, and Git.
3. Install Codex from the Microsoft Store.
4. Sign in successfully.
5. Open Settings > Configuration.
6. Click Diagnose or Reinstall under Workspace dependencies.
7. Observe that the dependency status returns to Not installed, and .sandbox-bin remains empty.

Expected behavior

The workspace dependencies should install successfully, the settings page should show a current installed version, and .sandbox-bin should contain the expected Codex runner/tool executables.

Additional notes

This looks like the Windows sandbox setup itself succeeds, but the dependency payload/tool binaries are not being downloaded, installed, or written into .sandbox-bin on this VPS environment.

[github-actions]

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

• Codex dependencies show as not installed and reinstall fails from Settings on Windows #21247
• Bug Report — Codex runtime bundle not provisioned (bundleVersion=null) #21116

Powered by Codex Action

[Kysta]

Resolved locally. Sharing the workaround in case it helps others.

The root cause in my case was not WebView2, VC++ Redistributable, Git, or the Microsoft Store install itself. Codex had successfully downloaded/selected the primary runtime config, but extraction failed while creating the runtime payload under the user cache directory.

The important log signal was:

Can't create '\\?\C:\Users\Admin\.cache\codex-runtimes\codex-runtime-install-...\payload\codex-primary-runtime\dependencies\node\node_modules\.pnpm\...' : Invalid argument
tar: Error exit delayed from previous errors.

After that, the UI kept showing workspace dependencies as Not installed, while .sandbox-bin remained empty.

What fixed it on this Windows 11 Enterprise VPS was enabling long paths / developer app model settings, resetting the failed Codex runtime/sandbox folders, then rebooting and clicking Reinstall again in Settings > Configuration > Workspace dependencies.

Commands run from an elevated PowerShell, with Codex closed:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\FileSystem" /v LongPathsEnabled /t REG_DWORD /d 1 /f

reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock" /v AllowDevelopmentWithoutDevLicense /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock" /v AllowAllTrustedApps /t REG_DWORD /d 1 /f

New-Item -ItemType Directory -Force "$env:USERPROFILE\.cache\codex-runtimes"
icacls "$env:USERPROFILE\.cache" /grant "$($env:USERNAME):(OI)(CI)F" /T

Remove-Item -Recurse -Force "$env:USERPROFILE\.cache\codex-runtimes" -ErrorAction SilentlyContinue
Remove-Item -Recurse -Force "$env:USERPROFILE\.codex\.sandbox-bin" -ErrorAction SilentlyContinue
Remove-Item -Recurse -Force "$env:USERPROFILE\.codex\.sandbox" -ErrorAction SilentlyContinue
Remove-Item -Recurse -Force "$env:USERPROFILE\.codex\.sandbox-secrets" -ErrorAction SilentlyContinue

Then reboot:

Restart-Computer

After restarting the VPS, I launched Codex again and clicked Reinstall under workspace dependencies. The install completed successfully and the UI now shows:

Current version: 26.506.11943

So for similar cases, I would suggest checking desktop logs for Can't create ... Invalid argument during extraction under .cache\codex-runtimes. If present, enabling Windows long paths and clearing the failed runtime/sandbox folders appears to resolve the issue.