Activity

1. eschulma

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on May 22, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   sandboxIssues related to permissions or sandboxingIssues related to permissions or sandboxing

   browser

   on May 22, 2026
3. jshaofa-ui commented on May 23, 2026

   

   jshaofa-ui

   on May 23, 2026

   More actions

   openai/codex #24101: Windows Desktop WSL Workspace Sandbox ACL Failures

   Issue Summary

   • Issue: Windows Desktop WSL workspace: node_repl/Browser/Chrome fail during sandbox ACL setup on \\wsl.localhost UNC path #24101
   • Type: Bug - sandbox ACL failures in WSL workspaces
   • Labels: bug, windows-os, sandbox, app, browser
   • Impact: node_repl, Browser, and Chrome tools fail during sandbox ACL operations
   • Competition: Zero (0 comments, 0 PRs)

   Root Cause Analysis

   1. WSL File System ACL Translation

   Windows Desktop running in WSL workspaces encounters ACL failures because:

   • NTFS vs ext4 ACL mismatch: WSL2 uses a 9P filesystem bridge (WSLdrv) that translates between Windows NTFS ACLs and Linux POSIX ACLs. The sandbox layer may apply ACLs that are valid on native Linux but fail when translated through WSLdrv.
   • Windows Security Descriptor translation: When Codex Desktop applies sandbox ACLs to WSL workspace files, the ACL translation layer may reject certain security descriptors that contain Windows-specific SIDs or inheritance flags.
   • Symbolic link / junction handling: WSL has specific rules about symlinks across the Windows/Linux boundary that may conflict with sandbox isolation requirements.

   2. Specific Failure Points

   Codex Desktop (Windows)
   ├── Sandbox Layer
   │   ├── applyACL(path, rules)     ← fails on WSL paths
   │   │   ├── translateToWindowsACL()  ← NTFS translation may fail
   │   │   └── setSecurityDescriptor()  ← Windows API rejection
   │   ├── validateWorkspaceAccess()
   │   │   └── checkFilePermissions()   ← WSLdrv 9P protocol limitations
   │   └── isolateProcess()
   │       └── mountNamespaces()        ← WSL2 doesn't support all Linux namespaces
   ├── Tools
   │   ├── node_repl    ← fails when sandbox ACL blocks access
   │   ├── Browser      ← fails when sandbox ACL blocks temp files
   │   └── Chrome       ← fails when sandbox ACL blocks profile directory
   └── WSL Bridge
       └── wsl.exe --exec  ← filesystem operations go through 9P
   

   3. WSL-Specific Factors

   • WSLdrv 9P limitations: The 9P protocol used by WSL2 has limited ACL support compared to native Linux
   • Metadata preservation: WSL stores extended attributes in alternate data streams (EAs in ADS), which may not be properly handled by the sandbox layer
   • Drive mounting: /mnt/c/ paths vs native WSL paths (\\wsl$\) have different ACL behaviors
   • Process isolation: WSL2 uses a lightweight VM with Hyper-V isolation, limiting Linux namespace support

   Fix Approach

   Component 1: WSL-Aware ACL Translation

   // BEFORE (fails on WSL):
   function applySandboxACL(workspacePath: string, rules: ACLRule[]): void {
     // Direct POSIX ACL application fails on WSLdrv-mounted paths
     rules.forEach(rule => {
       fs.setPosixACL(workspacePath, rule);  // ← throws on WSL
     });
   }
   
   // AFTER (WSL-aware):
   function applySandboxACL(workspacePath: string, rules: ACLRule[]): void {
     const wslInfo = detectWSLEnvironment();
     
     if (wslInfo.isWSL) {
       // Use WSL-compatible ACL approach
       applyWSLCompatibleACL(workspacePath, rules, wslInfo);
     } else {
       // Native Linux: use standard POSIX ACLs
       rules.forEach(rule => fs.setPosixACL(workspacePath, rule));
     }
   }
   
   function detectWSLEnvironment(): WSLInfo {
     const release = execSync('uname -r').toString().toLowerCase();
     const isWSL = release.includes('microsoft') || release.includes('wsland');
     
     return {
       isWSL,
       version: release.includes('microsoft') ? 2 : 1,
       isNativePath: !workspacePath.startsWith('/mnt/'),
       wslDist: execSync('wsl.exe -l -q').toString().trim(),
     };
4. walter-seethaler commented on Sep 1, 2026

   

   walter-seethaler

   on Sep 1, 2026 – with ChatGPT Codex Connector

   More actions

   Cross-linking #35380 as the broader reproduction of the same Windows-native WSL-UNC sandbox failure. This issue provides the earlier Browser/Chrome/node_repl ACL evidence; #35380 shows that the registered \\wsl.localhost root also blocks ordinary shell commands, including commands explicitly started from a local C:\ directory. Direct Win32 testing there further confirms GetNamedSecurityInfoW returning error 1 for multiple WSL providers.

   This is therefore not only a Browser-plugin failure. It is a global Windows sandbox initialization failure triggered by a WSL UNC workspace root.
5. rlh8177 commented on Sep 6, 2026

   

   rlh8177

   on Sep 6, 2026

   More actions

   Reproduced on 2026-09-06 with Codex Desktop 26.901.6511.0 (codex-command-runner 0.153.4), Windows x64 build 26200, and a WSL UNC workspace (\wsl$\Ubuntu\home<user>\src<repo>). Both exec_command and Computer Use failed before user code ran with helper_unknown_error: setup refresh had errors. The sandbox log shows write ACE check/grant failures on the workspace with GetSecurityInfo error 1, plus deny ACE failures on .git and .codex with GetNamedSecurityInfoW error 1. An escalated read-only command succeeds, confirming the requested shell/WSL command is not the failing layer. This remains reproducible in the current 26.901 app build.