Security concern: CodexSandboxOffline/Online assigned to entire user profile tree on Windows 11

It might also pollute your SSH configuration in ~/.ssh, as mentioned here: https://github.com/openai/codex/issues/12226

I just noticed the same problem. I have Windows 11 Controlled Folder Access active, meaning every application trying to access my user folder needs to be given explicit permission to do so.

I just installed the latest Codex extension for VS Code and started a conversation about reading and understanding the code of a simple test project and am getting absolutely swamped by Windows Notification about how Codex tries to access all kinds of files in my user directory, causing a new security notification every 2-3 seconds.

Why is it constantly trying to access my favorites? What is its deal trying to access my documents? The simple task I have given it does not warrant the try to read through my personal profile at all.

I see no reason why it should have any business inside my user profile at all.

I am having the same problem as 686d7066, IT messaged me pretty quickly.

Two other issues where Codex granted itself NTFS permissions:

• https://github.com/openai/codex/issues/14585
• https://github.com/openai/codex/issues/14006

In my case it added CodexSandboxOffline (or CodexSandboxOnline; i didn't realize there were two) to D:\.
And it removed all other ACLs that were present (blocking all users from the D: drive).

I noticed the same and got swamped by security warnings. This is really ugly and dangerous behaviour.

How has no one from Open AI replied to this? How is this still an ongoing issue? This also affects VSCode Codex extension users.

Does anyone know how to broadly and easily remove the ACL permissions for CodexSandboxUsers? Why the hell does Codex need read access for basically my entire computer?

Seems like a massive invasion of privacy and a serious screw up that Codex now has read access to basically my whole computer. And the weirdest thing is, I never had any issues before using Codex with VSCode, it was restricted to the project folder, it worked fine, and there was no invasive privacy problems. Then I was forced to accept this sandbox option 2-3 weeks ago and not only did it break functionality, it seems it's also a major privacy invasion whether intentional or not.

Why the hell does Codex need read access for basically my entire computer?

In my case it was correctly getting access denied. So it probably ran a powershell script call to icacls to try to resolve it. I assume it was running as me; who has WRITE_DACL permission on the D:\ folder. I didn't notice any such call. And when i asked it to review the chat conversataion: it couldn't find any call either.

In order to protect against this, i removed my WRITE_DACL permission from D:\.

I got hit by this issue after trying to SSH using private key but gave me an error to remove the SID first that has access to my SSH private key, that SID is associated to Codex users and I'm as surprised it assigned to every directory even AppData with Codex SIDs

I think I managed to resolve this though not sure if this is the broad solution, by removing two users from lusrmgr (for Windows Pro, home must use net comamnd) then on the user profile directory, on file explorer you need to click Give Access To > "Remove Access" which would take time

I believe you can also do this via icacls command though I don't fully use it

IMO unprivileged sandbox is more than enough, or just use WSL2

My biggest issue is that the modifications to user system are invasive but very poorly documented.

The Windows page only says,

ask your IT team whether the machine allows administrator-approved setup for local user/group creation, firewall configuration, and the required sandbox-user logon rights.

IT cannot possibly make decisions just based on this sentence alone.

Fortunately, codex is open source, and I figured out what codex-command-runner.exe does (implemented in codex-rs/windows-sandbox-rs) and was able to provide more details for IT to review. But the fact that this process is opaque is very concerning.

P.S. Plus there is no easy way to undo all of this, it seems.

---

I created a GitHub Gist that lists all changes to user system. I was not able to verify every detail but could confirm some of the most impactful changes.

thanks for reporting this. For now we likely won't change this, but if it bothers you for the codex sandbox users to have broad read access, you can change your sandbox (in config.toml) to

[windows]
sandbox = "unelevated"

and remove the ACLs. The unelevated sandbox will not recreate them.

This response misses the point entirely.

The problem is not that “Codex sandbox users have broad read access” and that this might merely “bother” someone. The real issue is that Codex appears to modify ACLs in a way that can break unrelated third-party applications on Windows, and that those effects can persist even after Codex has been uninstalled.

In my case, this was not theoretical and not cosmetic:

• Cricut Design Space stopped working because Electron child processes could no longer access required components.
• Procmon showed ACCESS DENIED on ffmpeg.dll for Cricut subprocesses.
• Vivaldi could no longer play DRM-protected content such as Netflix and failed with protected content errors.
• Reinstalling the affected applications did not fix the issue.
• The problem disappeared only after manually removing the Codex-related ACL entries again.

That is a serious regression, not a matter of preference about Codex having read access.

Saying “we likely won't change this” and suggesting users switch to sandbox = "unelevated" is not an acceptable answer to a bug report like this. Users should not have to weaken or reconfigure sandboxing, manually inspect ACLs across their user profile, and repair broken third-party applications after installing or uninstalling a developer tool.

Even worse, this is not limited to Codex being installed. The damage can remain after uninstall, which makes it substantially more severe. A tool must not leave behind deeply inherited ACL changes in sensitive per-user paths if those changes can interfere with Electron apps, browser DRM, or other software that relies on sandboxed subprocesses.

This needs to be treated as an actual Windows bug:

• Codex must not apply overly broad or persistent ACL changes in user profile paths.
• The installer and uninstaller must fully revert anything they create.
• No unrelated application should break, either while Codex is installed or after it has been removed.

Right now, the response reads as though the issue is being dismissed as a minor annoyance. It is not. Breaking unrelated applications and DRM playback on a user system is an absolute no-go.

I'd also like to point out I still have to manually correct permissions for
my SSH keys that I have on my computer, not something I'd do every time
sandboxing is being used, because Open SSH does not like that

I agree this does break applications where ACLs matter a lot, IMHO there should be other better ways to sandbox than resorting through this... and the unelevated sandboxing is more than enough for most users, and elevated should be for users who matter more on security.

On Sun, Apr 19, 2026, 3:54 AM seh-len @.***> wrote:

seh-len left a comment (openai/codex#12343) <https://github.com/openai/codex/issues/12343#issuecomment-4274455383> This response misses the point entirely. The problem is not that “Codex sandbox users have broad read access” and that this might merely “bother” someone. The real issue is that Codex appears to modify ACLs in a way that can break unrelated third-party applications on Windows, and that those effects can persist even after Codex has been uninstalled. In my case, this was not theoretical and not cosmetic: - Cricut Design Space stopped working because Electron child processes could no longer access required components. - Procmon showed ACCESS DENIED on ffmpeg.dll for Cricut subprocesses. - Vivaldi could no longer play DRM-protected content such as Netflix and failed with protected content errors. - Reinstalling the affected applications did not fix the issue. - The problem disappeared only after manually removing the Codex-related ACL entries again. That is a serious regression, not a matter of preference about Codex having read access. Saying “we likely won't change this” and suggesting users switch to sandbox = "unelevated" is not an acceptable answer to a bug report like this. Users should not have to weaken or reconfigure sandboxing, manually inspect ACLs across their user profile, and repair broken third-party applications after installing or uninstalling a developer tool. Even worse, this is not limited to Codex being installed. The damage can remain after uninstall, which makes it substantially more severe. A tool must not leave behind deeply inherited ACL changes in sensitive per-user paths if those changes can interfere with Electron apps, browser DRM, or other software that relies on sandboxed subprocesses. This needs to be treated as an actual Windows bug: - Codex must not apply overly broad or persistent ACL changes in user profile paths. - The installer and uninstaller must fully revert anything they create. - No unrelated application should break, either while Codex is installed or after it has been removed. Right now, the response reads as though the issue is being dismissed as a minor annoyance. It is not. Breaking unrelated applications and DRM playback on a user system is an absolute no-go. — Reply to this email directly, view it on GitHub <https://github.com/openai/codex/issues/12343?email_source=notifications&email_token=A4QQBQN4M62UDPAZEHHVDIL4WPMOZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMRXGQ2DKNJTHAZ2M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4274455383>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A4QQBQLGWW64AANMXTPTUHT4WPMOZAVCNFSM6AAAAACV2WEAIOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DENZUGQ2TKMZYGM> . You are receiving this because you commented.Message ID: @.***>

Just popping in to mention that this particular feature breaks windows built in ssh client, as it introduces bad permissions on ~/.ssh/config

Man, reading all this I feel lucky that Controlled Folder Access prevented this shit show for me and the worst of my problems was the constant notifications from Windows Security about Codex TRYING to apply this mess.

I really cant understand how the Codex team seemingly is simply brushing this of as nothing serious.

Open code app is a better alternative...

For anyone who has run into this problem and wants a quick fix, you can do the following in powershell, and then stop using codex

$acl = Get-Acl $env:USERPROFILE
$user = New-Object System.Security.Principal.SecurityIdentifier("<this would be your S-1-5-etc id of the user>") 
$acl.PurgeAccessRules($user)
Set-Acl -Path $env:USERPROFILE -AclObject $acl

and wants a quick fix

This is not a solution for this case, because the unwanted ACL entries were not only present on the profile root but had been stamped explicitly onto many individual subfolders throughout the user profile. Removing the ACE from %USERPROFILE% alone only changes that single directory and does nothing to clean up the large number of separate child-folder ACLs that were already written.

@seh-len I'm not super familiar with windows permissions, but it did in fact remove all of the entries from subdirectories and files when I ran it.

All of the subdirectories and files inherit the permission from the root due to inheritance, so when you remove the root, all the children lose it as well.

All of the subdirectories and files inherit the permission from the root due to inheritance

In my case, it wasn't inherited from the root folder, but was set separately for each individual subfolder.

so we have found temporary solutions by removing the permissions of lets say the 'home' directory but what about the sub folders in the ACL entries? Why is no OpenAI employee solving this major issue?

So in short what this thread is trying to say is that my windows machine is now cooked and I will have to boot up a fresh install?

a bunch of my scripts for SSH just stopped working because ssh refused to accept the private keys after Codex gave itself permissions to the key files.

This happens also on windows 10, just discovered it a while ago accidently. Codex definitely shouldn't create other users, even if they are labled as "Sandboxed users"; I don't see any reason for that to happen, and yes, opposed to what some of you may think, it is a security risk. Also if OpenAI doesn't want to change that behavior, the minimum is to alert the user that this is going to happen when installing the sandbox environment.