›_ Codex Issues
Codex Issues / #27236

Codex elevated Windows sandbox ACLs appear to break Electron/Chromium GPU sandbox for apps under AppData\Local

Open 💬 0 comments Opened Jun 9, 2026 by stippie-dot

What issue are you seeing?

Several unrelated Electron/Chromium desktop apps installed under C:\Users\<USER>\AppData\Local stopped launching on my Windows account after using Codex Desktop with the elevated Windows sandbox.

Affected apps include but are not limited to:

  • GitHub Desktop 3.5.10
  • Discord
  • opencode desktop
  • T3

The apps fail because Chromium/Electron’s GPU process repeatedly crashes. GitHub Desktop logs show:

[ERROR:content\browser\gpu\gpu_process_host.cc:1004] GPU process exited unexpectedly: exit_code=-2147483645
[WARNING:content\browser\gpu\gpu_process_host.cc:1446] The GPU process has crashed 1 time(s)
[ERROR:content\browser\gpu\gpu_process_host.cc:1004] GPU process exited unexpectedly: exit_code=-2147483645
[WARNING:content\browser\gpu\gpu_process_host.cc:1446] The GPU process has crashed 6 time(s)
[FATAL:content\browser\gpu\gpu_data_manager_impl_private.cc:415] GPU process isn't usable. Goodbye.

Launching the same app with --disable-gpu-sandbox works.

The issue appears related to ACLs applied by the Codex elevated Windows sandbox. The concern is not mainly that Codex-related sandbox identities have access to AppData, but that the resulting ACLs are inherited by unrelated Electron app install directories and appear to interfere with Chromium/Electron’s own GPU sandbox.

Relevant environment:

Windows: Windows 10.0.26200
Codex Desktop version: 26.602.30954
GitHub Desktop: 3.5.10
Codex sandbox mode: workspace-write
Windows sandbox: elevated

Relevant codex.toml excerpt:

model = "gpt-5.4"
model_reasoning_effort = "high"
approval_policy = "on-request"
sandbox_mode = "workspace-write"

[windows]
sandbox = "elevated"

# Trusted projects exist, but none point to:
# C:\Users\<USER>\AppData
# C:\Users\<USER>\AppData\Local
# C:\Users\<USER>

There is no explicit sandbox_workspace_write.writable_roots entry for AppData, AppData\Local, or the full user profile.

Relevant ACL observation:

C:\Users\<USER>\AppData\Local had Codex-related AppContainer/package SID entries with Full Control:

C:\Users\<USER>\AppData\Local
  S-1-15-2-<REDACTED>:(F)
  S-1-15-2-<REDACTED>:(OI)(CI)(IO)(F)
  S-1-15-2-<REDACTED>:(F)
  S-1-15-2-<REDACTED>:(OI)(CI)(IO)(F)
  S-1-15-2-<REDACTED>:(F)
  S-1-15-2-<REDACTED>:(OI)(CI)(IO)(F)
  <MACHINE>\CodexSandboxUsers:(OI)(CI)(RX)
  NT AUTHORITY\SYSTEM:(OI)(CI)(F)
  BUILTIN\Administrators:(OI)(CI)(F)
  <MACHINE>\<USER>:(OI)(CI)(F)

These ACLs were inherited by unrelated Electron app directories, including:

C:\Users\<USER>\AppData\Local\GitHubDesktop
C:\Users\<USER>\AppData\Local\GitHubDesktop\app-3.5.10
C:\Users\<USER>\AppData\Local\GitHubDesktop\app-3.5.10\GitHubDesktop.exe

A reset of ACLs on only the GitHub Desktop install folder fixed GitHub Desktop. After that, GitHub Desktop launched normally again without --disable-gpu-sandbox.

What steps can reproduce the bug?

I cannot provide a minimal code-only repro because the issue depends on the Windows ACL state created by the Codex elevated sandbox. However, these steps reproduce/diagnose the failure on my machine.

  1. Use Codex Desktop on Windows with elevated sandbox enabled:
sandbox_mode = "workspace-write"

[windows]
sandbox = "elevated"
  1. Confirm that C:\Users\<USER>\AppData\Local has Codex-related AppContainer/package SID ACLs with Full Control:
icacls "$env:LOCALAPPDATA"

Observed pattern:

S-1-15-2-...:(F)
S-1-15-2-...:(OI)(CI)(IO)(F)
  1. Launch GitHub Desktop normally from its installed path:
& "$env:LOCALAPPDATA\GitHubDesktop\Update.exe" --processStart GitHubDesktop.exe

Observed result: app does not open; Chromium GPU process repeatedly crashes.

  1. Launch GitHub Desktop with the GPU sandbox disabled:
& "$env:LOCALAPPDATA\GitHubDesktop\app-3.5.10\GitHubDesktop.exe" --disable-gpu-sandbox --enable-logging --v=1

Observed result: app opens.

  1. Copy the exact same GitHub Desktop app folder outside of AppData\Local:
$src = "$env:LOCALAPPDATA\GitHubDesktop\app-3.5.10"
$dst = "C:\ElectronPathTest\GitHubDesktop-app-3.5.10"

Remove-Item $dst -Recurse -Force -ErrorAction SilentlyContinue
New-Item -ItemType Directory "C:\ElectronPathTest" -Force | Out-Null
Copy-Item $src $dst -Recurse -Force

& "$dst\GitHubDesktop.exe" --enable-logging --v=1

Observed result: the app launches successfully without --disable-gpu-sandbox.

  1. Reset ACLs only on the original GitHub Desktop install folder:
taskkill /F /IM GitHubDesktop.exe /T 2>$null

$base = "$env:LOCALAPPDATA\GitHubDesktop"
$user = "$env:USERDOMAIN\$env:USERNAME"

takeown /F $base /R /D Y

icacls $base /inheritance:r /T

icacls $base /grant:r "${user}:(OI)(CI)F" /T
icacls $base /grant:r "*S-1-5-18:(OI)(CI)F" /T
icacls $base /grant:r "*S-1-5-32-544:(OI)(CI)F" /T
  1. Launch GitHub Desktop normally again:
& "$env:LOCALAPPDATA\GitHubDesktop\Update.exe" --processStart GitHubDesktop.exe

Observed result: GitHub Desktop launches normally.

Additional negative checks already performed:

  • Clean GPU driver reinstall did not fix the issue.
  • Clearing Chromium/GPU caches did not fix the issue.
  • AppCompatFlags contained no relevant entries.
  • UserGpuPreferences contained no relevant entries.
  • Startup apps were disabled and rebooted; no change.
  • TEMP permissions were tested and were not the cause.
  • A different Windows user account could launch the same Electron apps normally.

What is the expected behavior?

Codex elevated Windows sandbox ACLs should not interfere with unrelated Electron/Chromium desktop apps installed under C:\Users\<USER>\AppData\Local.

If Codex needs read access to profile locations, those ACLs should not cause unrelated app binaries, DLLs, or Chromium GPU child processes to fail sandbox initialization.

Write/full-control ACLs should be limited to the active workspace and explicitly configured writable roots. Since my config does not include AppData\Local, AppData, or the full user profile as writable roots, I would not expect Codex-related AppContainer/package SID entries with Full Control to be inherited by unrelated per-user installed desktop applications.

Expected behavior:

  • GitHub Desktop, Discord and other Electron apps should launch normally from AppData\Local.
  • Chromium/Electron GPU sandbox should not fail due to inherited Codex sandbox ACLs.
  • Codex should avoid applying ACLs in a way that affects unrelated per-user app install directories.
  • Codex should ideally provide a repair/cleanup command to remove stale or overly broad sandbox ACLs.

Additional information

This appears to be a compatibility issue between Codex elevated Windows sandbox ACLs and Chromium/Electron’s own sandboxing, not a normal GitHub Desktop or Discord issue.

The strongest evidence:

  1. The same GitHub Desktop binary failed from its original AppData\Local path.
  2. The same binary worked when copied to C:\ElectronPathTest.
  3. The app worked with --disable-gpu-sandbox.
  4. The app worked after resetting ACLs only on the original GitHub Desktop install folder.
  5. A separate Windows user account could run the app normally.
  6. Multiple unrelated Electron apps were affected.

The main request is to investigate whether Codex elevated Windows sandbox setup can leave or apply ACLs under AppData\Local that are inherited by unrelated Electron apps and cause Chromium GPU sandbox process creation to fail.

It would be helpful if Codex could:

  1. Avoid applying broad Full Control ACLs to C:\Users\<USER>\AppData\Local.
  2. Restrict write ACLs to the active workspace and configured writable roots only.
  3. Provide a diagnostic command showing what ACL changes Codex has applied.
  4. Provide a repair/cleanup command to remove stale or overly broad Codex sandbox ACLs.
  5. Document which ACL entries are expected for CodexSandboxUsers and AppContainer/package SIDs in elevated Windows sandbox mode.

View original on GitHub ↗