Skip to content

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

Open
Open
Windows sandbox setup refresh fails for workspace on \\wsl.localhost UNC path#35380
Labels
appIssues related to the Codex desktop appbugSomething isn't workingsandboxIssues related to permissions or sandboxingwindows-osIssues related to Codex on Windows systems

Description

@Keno-Chile
Keno-Chile
opened on Jul 25, 2026

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.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    sandboxIssues related to permissions or sandboxing
    on Jul 25, 2026

  2. github-actions commented on Jul 25, 2026

    @github-actions
    github-actionsBot
    on Jul 25, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. walter-seethaler commented on Jul 29, 2026

    @walter-seethaler
    walter-seethaler
    on Jul 29, 2026 – with ChatGPT Codex Connector

    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.

  4. walter-seethaler commented on Aug 25, 2026

    @walter-seethaler
    walter-seethaler
    on Aug 25, 2026 – with ChatGPT Codex Connector

    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.

  5. TTvede commented on Aug 28, 2026

    @TTvede
    TTvede
    on Aug 28, 2026

    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.

  6. walter-seethaler commented on Sep 1, 2026

    @walter-seethaler
    walter-seethaler
    on Sep 1, 2026 – with ChatGPT Codex Connector

    Cross-issue scope and status update (2026-09-01):

    I reviewed the open reports around WSL and UNC handling. They do not all demonstrate the same root cause, but they expose a broader support gap in Codex Desktop on Windows.

    Direct Windows-native WSL-UNC sandbox family:

    Related WSL Desktop integration problems, not confirmed duplicates: #18506, #23894, #24884, #29347, #32108, and #36850.

    Broader UNC, SMB, mapped-drive, and virtual-filesystem problems, not necessarily the same cause: #10347, #12350, #19599, #25422, #27307, #35476, and #38347.

    Switching the Agent environment to WSL is not an equivalent workaround for Windows-centric projects. It reverses the boundary: Windows files are then reached through /mnt/c, while separate reports document incorrect path translation, CWD and CODEX_HOME state, file-preview links, and Browser/Chrome integration. A complete implementation needs to keep Windows roots on the Windows-native runtime and WSL roots on a WSL-native runtime, with explicit path translation at Desktop integration boundaries. At minimum, an unsupported root must be rejected with an actionable message instead of poisoning all unrelated local tools in the task.

    For weeks, this issue cluster has remained without an assigned maintainer, a milestone, a coordinated OpenAI response, or a linked fix. Codex Desktop accepts WSL-backed workspaces through their standard Windows UNC representation without warning, yet the Windows-native sandbox cannot use them and the suggested WSL mode is not an equivalent replacement for Windows workflows. Calling this supported without those qualifications is misleading.

    It is deeply frustrating and disappointing to see rapid product and feature development while an entire cluster of bugs that disables core application functionality remains unresolved. New features have little value when fundamental workspace support remains broken and unattended.

  7. rozsazoltan commented on Sep 15, 2026

    @rozsazoltan
    rozsazoltan
    on Sep 15, 2026

    After Windows wakes from sleep, every application that relies on WSL becomes unusable for me for some reason, including VS Code and Codex. Restarting the applications alone does not fix it.

    Until the underlying issue is found, this recovery sequence has worked reliably every time:

    1. Close affected applications, including Codex.
    2. Run:
    wsl --shutdown
    1. Start WSL again:
    wsl
    1. Reopen affected applications, including Codex.

    I'm not sure whether the interaction between Windows sleep and WSL depends on some specific system configuration.

    What makes this particularly strange is that terminals and file managers continue to access WSL correctly and can execute commands inside it without any problems. Only Windows desktop applications seem to break after waking from sleep.

    For me, this happens consistently, without exception, regardless of which WSL distribution or desktop application is involved.

  8. akashskypatel commented on Sep 23, 2026

    @akashskypatel
    akashskypatel
    on Sep 23, 2026

    Reproduced on Codex Desktop 26.917.8451.0.

    The active Windows workspace was:

    D:\Projects\windows-repo

    while the sandbox writable roots still included a WSL UNC repo:

    \\wsl.localhost\Distro\home\user\wsl-repo

    Desktop logs show:

    requestSandboxPolicyType=workspaceWrite
requestSandboxWritableRootCount=3
requestRuntimeWorkspaceRootCount=0

    The sandbox helper then fails specifically on the WSL root:

    write ACE check failed on \\?\UNC\wsl.localhost\Distro\home\user\wsl-repo:
GetSecurityInfo failed ...: 1

write ACE grant failed ...

    ACL operations on normal Windows paths in the same refresh succeed, but the WSL failures are aggregated and abort the entire refresh:

    setup refresh: processed 4 write roots ... errors=[...]
setup refresh completed with errors
setup error: setup refresh had errors
setup refresh: exited with status 1

    The deny-ACE pass also fails against both \\?\UNC\wsl.localhost\... and ordinary \\wsl.localhost\..., so extended-path normalization does not avoid the problem.

    This confirms the issue is still present in 26.917.8451.0 and that a registered WSL writable root can break otherwise unrelated Windows-local execution.

  9. Xain3 commented on Sep 30, 2026

    @Xain3
    Xain3
    on Sep 30, 2026 – with ChatGPT Codex Connector

    Additional reproduction on 30 September 2026 with Ubuntu and a Windows-native Codex agent (workspace-write sandbox). Personal path segments below are redacted.

    Environment verified in the current Windows-local diagnostic chat:

    • Windows version: 10.0.26300.9457 (reported by wsl.exe --version)
    • Bundled CLI: codex-cli 0.159.2
    • Agent command shell: PowerShell Core 7.6.6
    • Codex desktop app: 26.928.21956
    • WSL: 2.7.8.0; kernel: 6.18.33.1-1; WSLg: 1.0.73.2 (verified with wsl.exe --version, which succeeds inside the sandbox)

    Two earlier chats had a registered workspace under:

    \\wsl.localhost\Ubuntu\home\<user>\programming\<repo>

    Even a read-only command failed before starting:

    Failed to create unified exec process: helper_unknown_error: setup refresh had errors

    Retrying the command with an explicit Windows-local working directory (C:\Users\<user>) produced the same error while the chat retained the WSL workspace.

    The local sandbox.2026-09-30.log directly confirms failed Windows permission operations on the WSL root and its .git directory. Representative redacted entries:

    write ACE check failed on \\?\UNC\wsl.localhost\Ubuntu\home\<user>\programming\<repo>: GetSecurityInfo failed for \\?\UNC\wsl.localhost\Ubuntu\home\<user>\programming\<repo>: 1; continuing
write ACE grant failed on \\?\UNC\wsl.localhost\Ubuntu\home\<user>\programming\<repo>: GetSecurityInfo failed for \\?\UNC\wsl.localhost\Ubuntu\home\<user>\programming\<repo>: 1
deny ACE failed on \\wsl.localhost\Ubuntu\home\<user>\programming\<repo>\.git: GetSecurityInfo failed for \\wsl.localhost\Ubuntu\home\<user>\programming\<repo>\.git: 1
setup error: setup refresh had errors

    Control comparison: a new chat in a Windows-local folder under C:\Users\<user>\Documents\Codex\... successfully ran commands, initialized Windows computer use, opened a browser, and typed/saved a test message in Notepad. Later sandbox refresh entries for Windows-local tests show errors=[].

    A separate failure remains in that working Windows-local sandbox: launching wsl.exe returns Wsl/Service/CreateInstance/E_ACCESSDENIED, whereas an identical harmless command succeeds outside the sandbox. I am reporting that separately on #21470; these are distinct observed failure modes, without asserting a shared root cause.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingsandboxIssues related to permissions or sandboxingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions