Codex sandbox installation corrupts ACL on AppData
What version of the Codex App are you using (From “About Codex” dialog)?
26.313.5234
What subscription do you have?
Free
What platform is your computer?
Microsoft Windows NT 10.0.19045.0 x64
What issue are you seeing?
Description
After installing Codex on Windows 10 and subsequently enabling/installing its sandbox component, Opera, Opera GX, and Opera Developer fail to launch entirely. The browsers flash a black screen 2–3 times and silently close. The issue appears specifically after the sandbox setup step, not immediately after the initial Codex installation. Chrome (stable) and Brave are unaffected.
Root Cause
Codex creates a local Windows group CodexSandboxUsers and local users CodexSandboxOffline / CodexSandboxOnline during installation, and modifies ACL permissions on AppData\Local.
This breaks the Chromium sandbox for any browser installed under AppData\Local (Opera, Opera GX, Chrome Canary), because the GPU process requires the ALL APPLICATION PACKAGES (S-1-15-2-1) permission on that path to launch in sandboxed mode.
Browsers installed in Program Files (Chrome stable, Brave, Edge) are unaffected because their AppData\Local path is not involved in the same way.
What steps can reproduce the bug?
- Install Codex on Windows 10
- Go through the sandbox setup/activation step within Codex
- Launch Opera, Opera GX, or Opera Developer → browser closes immediately
What is the expected behavior?
The sandbox installation step should not modify ACL permissions on AppData\Local in a way that affects other applications, or should at minimum restore them on uninstall/rollback.
26 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Hi @thunderstatic
We don’t intentionally remove existing ACLs on $env:LOCALAPPDATA. In the Windows sandbox setup path we read the existing DACL and merge in Codex allow ACEs, so if this is breaking Opera/Chrome Canary, the most helpful next step is to inspect the actual ACLs on the affected paths.
Could you run these in PowerShell and paste the output?
paths might vary slightly so skip or replace as needed. We mainly want to check whether ALL APPLICATION PACKAGES / ALL RESTRICTED APPLICATION PACKAGES are actually missing, and whether CodexSandboxUsers was added on those paths.
@iceweasel-oai here are the results. Note: I have already uninstalled Codex and ran
icacls /resetonAppData\Localto restore permissions before capturing this output, so this reflects the post-fix state.If you need the ACL state captured while the Codex sandbox is still installed (before the fix), I can reinstall the sandbox component and provide the output. Just let me know.
The two S-1-15-3-* SIDs visible on the Opera folder are app container SIDs added by Opera's own installer — those are expected and unrelated to the Codex issue, i guess.
Update: I reinstalled Codex to reproduce the issue, but it picked up my existing configuration and skipped the sandbox initialization step entirely — the CodexSandboxUsers group and sandbox users were not recreated. Not sure how to force that step at this point.
If you know a way to reset the sandbox setup (a flag, clearing some config, etc.), I'm happy to give it another shot.
Update 2: looks like I'm now in a softlock — every command fails with a sandbox error, for example:
This happens because I deleted the
CodexSandboxOfflineuser as part of the manual fix, and now Codex can't resolve its SID. The app has no obvious way to reinitialize the sandbox from scratch, so there's no way to get back to a clean state without manually recreating the users — which feels like something the app itself should handle.Managed to trigger sandbox reinitialization by deleting
.codex\.sandbox\setup_marker.json. Here's the output with sandbox freshly installed:As you can see, sandbox setup adds
CodexSandboxUsersand a new app container SID (S-1-15-2-2968813833-...) toAppData\Local\Programsand subdirectories. I don't know what changed but the Opera is broken again.For context: this issue is based on the thread at https://www.reddit.com/r/operabrowser/comments/1rvqlst/ — the root cause, symptoms and fix are taken from there.
The only difference is that instead of the suggested fix:
I used:
And it worked fine and the browser works again.
Interesting. The S-1-15-2-... AppContainer/capability SID with (F) is the kind of ACL we add when the sandbox treats a directory as a writable root, not just a readable one. That makes me suspect C:\Users\Daniil\AppData\Local\Programs may have been used as Codex’s active project/workspace directory at some point. Did you ever run or initialize Codex with AppData, AppData\Local, or AppData\Local\Programs as the project directory?
No, my first and last project was at
C:\Users\Daniil\source\workI'm not 100% sure though — I don't remember what directory was used for the first test project that Codex suggests on initial setup. I think I just closed it right away.
would you be willing to send me your
sandbox.logfile? It's located at%USERPROFILE%\.codex\.sandbox\sandbox.logSure! I did see that file earlier. I removed a couple of lines containing email addresses, but otherwise it's untouched.
The second attempt to grant permissions was likely interrupted by me, that's when I noticed the browser was broken again (the last line)
sandbox.log
Thanks for sending this. It’s clear that AppData\Local\Programs and its children have a write ACE for the Codex capability/AppContainer SID, but the sandbox.log we’ve seen does not show anything directly granting write access there, so I’m not yet sure where that ACE is coming from.
It’s also odd that the write ACE on AppData\Local\Programs is marked as inherited, but it doesn’t appear on the parent AppData\Local directory. Under normal NTFS inheritance, that shouldn’t happen.
Could you run these as well?
```
icacls "$env:USERPROFILE\AppData"
Get-Item "$env:LOCALAPPDATA\Programs" | Format-List FullName,Attributes,LinkType,Target
For now is:
Thanks, this rules out Programs being a junction, and it also shows AppData itself doesn’t have the capability SID either. So we still have a contradiction: AppData\Local\Programs shows the bad capability ACE as inherited, but neither AppData nor
AppData\Local show it on the parent chain.
Could you run these too? I appreciate the help debugging this
It’s still not clear why AppData\Local\Programs shows an inherited ACE that its ancestors don’t seem to have.
If you’re up for helping debug it a bit more on your side, the most useful next step would be to reproduce it once from a clean state, confirm which sandbox mode you enabled, and then capture the sandbox.log plus the ACLs for AppData, AppData\Local,
AppData\Local\Programs, and Opera immediately afterward, before anything else changes. If not, no worries — this is already enough for us to keep investigating on our side.
I'm ready to proceed. Would deleting the sandbox marker file again be enough to reset it? The app doesn't seem to have any other way to trigger reinitialization from the UI.
yeah, the app doesn't really support "clearing the sandbox" - I use this locally:
and then update my ~\.codex\config.toml` to remove
My steps
``
execution error: Io(Custom { kind: Other, error: "windows sandbox: setup refresh failed with status exit code: 1" })
default permissionsare already setsetup_marker.jsonfrom the.sandboxfolder (nothing else was changed; this was done slightly before your advice)--no-sandboxis used)ACL for
%LOCALAPPDATA%ACL for
%LOCALAPPDATA%\ProgramsACL for
%LOCALAPPDATA%\Programs\OperaThere were some issues with the log file. :(
It appears that because the file was opened multiple times, I am seeing different sets of logs from the latest run depending on the instance. It looks like the data may have been corrupted due to having multiple open handles to the same file.
Sorry about that, I can try to reproduce the issue again and provide a clean log if the current data is not sufficient.
It’s all that’s left
ACL after another fix with
icacls /reset:This is not limited to AppData.
In my case, the Codex-related ACL entries were not confined to
AppData\Local; they ended up spread across folders throughout the entire user profile underC:\Users\<USER>. That makes this substantially worse than what the current issue title/body suggests.See also #12343, especially the teams response here:
https://github.com/openai/codex/issues/12343#issuecomment-4208289855
The suggestion that users can “just remove the ACLs” is frankly an unacceptable response.
Once these entries have been stamped onto a large number of folders across the full profile tree, cleanup is no longer trivial. At that point, users are expected to manually inspect and repair ACLs across a huge number of directories, with real risk of breaking permissions further or missing affected paths. That is not a reasonable workaround for damage caused by installing a developer tool.
More importantly, this is not about whether Codex sandbox users having read access is merely “annoying.” The real problem is that these ACL changes can break unrelated software. In my case, this resulted in third-party applications no longer functioning correctly, including Electron-based software and DRM-protected browser playback.
That is an absolute no-go.
A tool like this must not modify permissions so broadly across the user profile, and it absolutely must not leave users with a large-scale, high-risk ACL cleanup problem afterwards. This should be treated as a serious Windows bug, not brushed off as something users can fix themselves if it “bothers” them.
Windows 10/11 Codex app sandbox ACL issue confirmed on my machine.
After installing/enabling Codex Windows sandbox, both Opera and Opera GX, as well as other Chromium apps like Obsidian, failed to launch normally. They showed a black window, closed, retried several times, then stopped. Fresh reinstall of Opera did not help.
Codex Windows sandbox ACL regression / AppData Local permissions broke at least Opera, Opera GX, and Obsidian.
Diagnostics:
--disable-gpu.--no-sandbox.CodexSandboxUsersand orphaned unknown SIDs remaining after uninstall of CODEX.Repair:
ALL APPLICATION PACKAGESread-execute access on%LOCALAPPDATA%restored Opera and Obsidian.icacls "$env:LOCALAPPDATA" /grant "*S-1-15-2-1:(RX)" /CThis appears to affect Chromium/Electron app sandbox startup under
%LOCALAPPDATA%, not just Opera.Hi guys, I think this is a critical issue. I was curious to try out Codex in my Unity projects. I installed it two days ago, and everything was working fine right after installation and yesterday, but today... it’s a different story. I spent three hours trying to figure out why the Discord, Signal, and Notion apps stopped launching.
In my opinion, it is unacceptable that installing one application causes others to break WITHOUT THE ABILITY TO REVERSE IT! Because running
icacls /grant ...does indeed fix the problem, but it is a fix, not a reversal of the harmful changes introduced by Codex app.Definitely!
I was excited to test Codex, but now I'm really discouraged.
Additional Windows 11 reproduction: Codex sandbox/user ACL state caused
%LOCALAPPDATA%\Packagesto lose inherited SYSTEM access, breaking Codex and Windows packaged applications (or how I learned to stop worrying and love loosing 3 hours of my life)I appear to be encountering the same class of problem described in this issue, but with broader impact across Windows packaged applications. I captured the ACL state before repairing it, along with AppModel Runtime events and a Process Monitor trace.
Codex version
OpenAI.Codex_26.611.7849.0_x64__2p2nqsd0c76g0This is the package version reported by Windows. The application initially could not launch, so I could not open the About dialog before repair.
Subscription
ChatGPT Plus
Platform
Official Codex issue-template command output:
```text id="platform_official"
Microsoft Windows NT 10.0.26200.0 x64
Although
Get-ComputerInforeportsWindows 10 Pro, this is a Windows 11 system reporting the NT version family as10.0.What issue am I seeing?
After restarting Windows on June 16, 2026, the following began occurring:
MicrosoftWindows.Client.CBS, includingCrossDeviceResume.Windows Event Viewer recorded repeated AppModel Runtime Event 208 errors:
```text id="codex_event_208"
0x80070005: Cannot create the process for package
OpenAI.Codex_26.611.7849.0_x64__2p2nqsd0c76g0
because an error was encountered while configuring runtime.
[LaunchProcess]
This indicates that the failure was not limited to the Codex executable. It affected the shared Windows packaged-app runtime environment.
Process Monitor evidence
During a Codex launch attempt, Process Monitor captured
ACCESS DENIEDfrom a Windows runtime service while trying to access Codex’s package data directory:```text id="procmon_denied"
Process: svchost.exe
Operation: CreateFile
Path: %USERPROFILE%\AppData\Local\Packages\
OpenAI.Codex_2p2nqsd0c76g0\SystemAppData\Helium
Result: ACCESS DENIED
Desired access: Read Attributes
Options: Open Reparse Point
However, the packaged-app data directory had inheritance disabled and only my user account was present:
```text id="packages_before"
%USERPROFILE%\AppData\Local\Packages
Owner: <HOST>\<USER>
Inheritance disabled: True
<HOST>\<USER> FullControl Allow
I did not modify
%LOCALAPPDATA%\Microsoftbecause the Process Monitor evidence specifically implicated%LOCALAPPDATA%\Packages.The following Codex-created identities were present on the system:
```text id="codex_identities"
<HOST>\CodexSandboxUsers
<HOST>\CodexSandboxOnline
<HOST>\CodexSandboxOffline
I then made two changes before restarting, so I cannot isolate which change was necessary or sufficient:
```toml id="unelevated_config"
[windows]
sandbox = "unelevated"
The repair was performed by calling:
```powershell id="repair_method"
$acl.SetAccessRuleProtection($false, $true)
Set-Acl -LiteralPath $path -AclObject $acl
I also verified that the Codex package-data paths had inherited SYSTEM access:
```text id="codex_acl_after"
%LOCALAPPDATA%\Packages
InheritanceDisabled: False
SystemRights: FullControl
%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0
InheritanceDisabled: False
SystemRights: FullControl
%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\SystemAppData
InheritanceDisabled: False
SystemRights: FullControl
%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\SystemAppData\Helium
InheritanceDisabled: False
SystemRights: FullControl
```text id="codex_success_events"
Id 201: Created process for application OpenAI.Codex_2p2nqsd0c76g0!App
Id 210: Created Desktop AppX container for package OpenAI.Codex_26.611.7849.0_x64__2p2nqsd0c76g0
Id 211: Added process to Desktop AppX container for package OpenAI.Codex_26.611.7849.0_x64__2p2nqsd0c76g0
```text id="commandpalette_success_events"
Id 201: Created process for application Microsoft.CommandPalette_8wekyb3d8bbwe!App
Id 210: Created Desktop AppX container
Id 211: Added process to Desktop AppX container
The machine-wide registry permission for:
```text id="hklm_control"
HKLM\SYSTEM\CurrentControlSet\Control
I then queried AppModel Runtime events since boot for Codex, CrossDevice, Command Palette, Client.CBS, and
0x80070005.The only matching event IDs after repair were informational success events:
A follow-up query for Event ID 208, warnings, errors,
0x80070005, orAccess is deniedreturned no results.I also verified that the Codex package data paths retained inherited SYSTEM access after repair:
This indicates that restoring inherited ACLs and switching Codex to
sandbox = "unelevated"resolved the observed launch failures on my system. Because both changes were applied before rebooting, I cannot determine which change was individually necessary or sufficient.Expected behavior
Codex sandbox setup should merge any required Codex ACEs into the existing ACL without:
%LOCALAPPDATA%\PackagesThe installer, updater, and uninstaller should validate and preserve existing ACLs and roll back partially applied permission changes if setup fails.
Suggested safeguards
Potential safeguards could include:
I can provide sanitized copies of:
Workaround that resolved the issue on my machine
This is not an official fix, but the following steps resolved the issue on my affected Windows profile.
First, I changed Codex to use the unelevated Windows sandbox by editing:
and setting:
Then I backed up the current ACL state:
Then I re-enabled inheritance, while preserving existing explicit ACL rules, on
%LOCALAPPDATA%\Packagesand the package-data directories that were failing:Finally, I rebooted Windows. After reboot, the startup permission popup disappeared, Codex launched successfully, and no new AppModel Runtime Event 208 /
0x80070005launch failures were found.