›_ Codex Issues
Codex Issues / #35380

Windows sandbox setup refresh fails for workspace on \\wsl.localhost UNC path

Open 💬 4 comments Opened Jul 25, 2026 by Keno-Chile
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

The Codex desktop app cannot start any sandboxed shell command when the saved workspace root is a WSL2 UNC path such as \\wsl.localhost\Debian\home\<user>\<repo>.

The failure happens during sandbox preparation, before the requested command starts:

windows sandbox: helper_unknown_error: setup refresh had errors

Environment

  • Codex desktop app: OpenAI.Codex 26.721.4979.0 (Microsoft Store package)
  • Windows build: 26200
  • WSL: 2.9.3.0
  • WSL kernel: 6.18.35.2-1
  • Distribution: Debian, WSL2
  • bubblewrap: 0.11.0
  • Sandbox mode: workspace-write
  • Shell host for the affected thread: PowerShell / Windows-native agent

Steps to reproduce

  1. Add/open a Git repository located under \\wsl.localhost\Debian\home\<user>\<repo> in the Windows desktop app.
  2. Start a task using the normal workspace-write sandbox.
  3. Run a read-only command such as git status --short with that UNC path as the working directory.
  4. The sandbox fails during setup refresh before Git runs.
  5. Retry from C:\Windows while invoking wsl.exe -d Debian --cd /home/<user>/<repo> git status --short inside the normal sandbox. The same setup-refresh error occurs, apparently because the thread still has the UNC workspace root registered.

Expected behavior

The Windows sandbox should either support the registered WSL UNC workspace root, route the operation through WSL, or provide a specific actionable error directing the user to switch the agent runtime to WSL.

Actual behavior

Every normal sandboxed shell invocation fails with helper_unknown_error: setup refresh had errors, including commands whose explicit working directory is on C:\.

Isolation / workaround

  • Restarting both WSL (wsl --shutdown) and the Codex app does not resolve the issue.
  • wsl --update reports that the latest WSL version is installed.
  • The same Git command succeeds with exit code 0 when wsl.exe is executed outside the Windows sandbox.
  • The documented workaround is to switch Settings → agent → WSL and restart the app, or keep using explicit approved execution outside the Windows sandbox.

A separate line is sometimes printed after successful out-of-sandbox wsl.exe calls:

[0x...] ANOMALY: meaningless REX prefix used

It does not change the successful exit code and may be unrelated.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 1 month ago

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

  • #35353

Powered by Codex Action

walter-seethaler · 29 days ago

I reproduced this issue and can add a few details about scope and recovery.

Environment:

  • Codex Desktop on Windows
  • Windows version: 10.0.26200.8894
  • Initially configured workspace: a local C:\...\<repo> directory
  • Additional workspace folder: \\wsl.localhost\Ubuntu-24.04\home\<user>\<repo>

Before adding the WSL UNC folder, I ran the following five independent shell_command calls, each explicitly using sandbox_permissions: "use_default":

  1. Get-Date -Format o
  2. Get-Location
  3. Get-Content -LiteralPath '.\AGENTS.md' -TotalCount 1
  4. git --version
  5. cmd.exe /c ver

All five commands completed without escalation and with exit code 0. The Windows sandbox worked normally, and Computer Use could inspect IntelliJ IDEA successfully.

After adding the WSL UNC folder, I repeated the same five commands with the same sandbox settings. All five failed before the requested command started with:

windows sandbox: helper_unknown_error: setup refresh had errors

None of these commands accessed the UNC path. Merely registering it as an additional workspace root was sufficient to break the global sandbox refresh. Node REPL and Computer Use then also failed during sandbox startup with the same error.

Recovery behavior:

  • Removing the UNC folder from the existing project did not restore sandbox operation.
  • Fully restarting the desktop app did not restore it either.
  • Creating a new project containing only the same local workspace restored normal operation. The same five commands again completed without escalation and with exit code 0.

This directly corroborates the reported WSL UNC trigger and additionally indicates that the failing root configuration or derived sandbox state remains persisted for the existing project/task after the UNC root is removed. A newly created local-only project does not inherit the failure.

walter-seethaler · 3 days ago

Follow-up with direct Win32 API evidence and a current-source check.

I called GetNamedSecurityInfoW directly through a read-only P/Invoke probe using SE_FILE_OBJECT and DACL_SECURITY_INFORMATION. This bypasses PowerShell Get-Acl and does not modify any ACL.

Results on one Windows host:

| Path class | Result |
|---|---:|
| Native local NTFS path (C:\<local-workspace>) | 0 — success |
| \\wsl.localhost\Ubuntu-24.04\home | 1 — ERROR_INVALID_FUNCTION |
| \\wsl.localhost\Debian\home | 1 — ERROR_INVALID_FUNCTION |
| \\wsl.localhost\docker-desktop\tmp | 1 — ERROR_INVALID_FUNCTION |
| \\wsl$\Ubuntu-24.04\home | 1 — ERROR_INVALID_FUNCTION |
| Same local NTFS workspace reached through \\wsl.localhost\Ubuntu-24.04\mnt\c\<local-workspace> | 5 — ERROR_ACCESS_DENIED |

Environment: Windows 10.0.26200.8973, WSL 2.3.26.0, kernel 5.15.167.4-1; Ubuntu 24.04.4 LTS and Debian 13 run as WSL2 distributions.

This narrows the failure to the Windows ACL operation across the WSL UNC provider. It is not introduced by Get-Acl, not specific to Ubuntu versus Debian, and not specific to the \\wsl.localhost alias. Native Linux paths exposed by the provider reject the DACL query with code 1; even an underlying NTFS path that succeeds through C:\ fails when addressed through the WSL UNC/DrvFs route.

The current public source still appears to apply ensure_allow_write_aces to configured write roots, aggregate any failure into refresh_errors, hard-fail refresh with setup refresh had errors, and map that untyped failure to HelperUnknownError:

Repository search at that revision found no WSL-UNC, remote-drive, or FILE_PERSISTENT_ACLS preflight in this path. A safe fix likely needs either WSL-aware routing or an explicit unsupported-root classification before Windows DACL mutation; one incompatible root should also not poison unrelated local commands.

TTvede · 5 hours ago

Reproduced on a current Windows desktop build with the same WSL UNC trigger and broader impact across all local execution surfaces.

Environment:

  • Codex Desktop package before update: OpenAI.Codex 26.820.9563.0
  • Codex Desktop package after in-app update: OpenAI.Codex 26.825.3734.0
  • Windows: Microsoft Windows NT 10.0.26200.0
  • WSL: 2.7.11.0
  • WSL kernel: 6.18.33.2-2
  • Distribution: Ubuntu, WSL2
  • Sandbox mode supplied to the thread: workspace-write
  • No approval_policy, sandbox_mode, or untrusted override in the user config
  • Workspace roots include native Linux repositories exposed as \wsl.localhost\Ubuntu\home\<user>\<repo> plus one local Windows documentation folder

Observed:

  1. Any normal exec fails before the requested process starts, including PowerShell, cmd.exe, and wsl.exe, with: Failed to create unified exec process: helper_unknown_error: setup refresh had errors.
  2. The identical wsl.exe commands succeed with exit code 0 when explicitly approved outside the sandbox. WSL, Git, repository access, and network calls are healthy.
  3. Browser, Chrome extension control, and Computer Use all fail before their code runs because the local helper exits with: windows sandbox failed: helper_unknown_error: setup refresh had errors.
  4. The Chrome extension is installed, connected, and enabled in Settings > Computer use. The in-app browser is enabled.
  5. Restarting WSL, Windows, and Codex did not help. Renaming/rebuilding the Codex runtime cache did not help. Removing some UNC roots from the project did not help.
  6. Updating Codex Desktop from 26.820.9563.0 to 26.825.3734.0 did not change the failure. Normal shell and Chrome were retested after the update and still fail during setup refresh.

Impact:

  • Repository work is possible only through repeated out-of-sandbox approvals.
  • Browser, Chrome, and Computer Use have no equivalent escalation path, so authenticated dashboard verification and end-to-end autonomous work are impossible in the affected WSL project.

The issue body mentions switching Settings > agent > WSL as a workaround. In app 26.825.3734.0 the current Settings navigation shows Configuration, Environments, Worktrees, Browser, and Computer use, but no Agent entry or discoverable Windows-to-WSL runtime selector. Please either expose/document the current location of this switch or make WSL UNC roots route through a WSL-native sandbox automatically.

This also reproduces the Browser/Chrome symptom tracked in #24101.