Windows elevated sandbox grants write ACEs on NTUSER.DAT hive files, breaking the interactive user's profile load (temporary profile at sign-in)

[ishiguro-tech]

What version of Codex are you using?

npm @openai/codex (CLI) + Codex Desktop 26.623.42026. The write-ACE grants below were logged by the sandbox setup shipped around June 2026 (command-runner 0.13x–0.140 era); currently on command-runner 0.142.3.

What platform is your computer?

Microsoft Windows 11 Home 10.0.26200 x64

What issue are you seeing?

Summary

With [windows] sandbox = "elevated" and the user's home directory (C:\Users\<name>) registered as a trusted project, the Windows sandbox setup (codex-windows-sandbox-setup.exe) enumerates files under the workspace root and grants Modify + Delete Child ACEs to the CodexSandboxUsers group and a per-path capability SID on each file — including the user's registry hive files:

• NTUSER.DAT
• ntuser.dat.LOG1 / ntuser.dat.LOG2
• ntuser.ini
• NTUSER.DAT{...}.TM.blf
• NTUSER.DAT{...}.TMContainer...regtrans-ms

After these ACEs were applied, Windows User Profile Service began intermittently failing to load my (the interactive user's) profile at sign-in — Event IDs 1500/1508/1511/1515, "access denied" on the hive — falling back to a temporary profile.

Note this is distinct from #21455 (leaked TEMP.* profiles from failed sandbox-user logons): here the ACL mutation on the hive breaks loading of the real user's own profile. Related ACL-mutation reports: #15777 (AppData), #29415 (policy request to disable DACL mutation).

Evidence

~/.codex/.sandbox/sandbox.log:

[2026-06-18T15:44:04.864475400+00:00] granting write ACE to C:\Users\black\NTUSER.DAT for sandbox group and capability SID
[2026-06-18T15:44:04.865219500+00:00] granting write ACE to C:\Users\black\ntuser.dat.LOG1 for sandbox group and capability SID
[2026-06-18T15:44:04.865962700+00:00] granting write ACE to C:\Users\black\ntuser.dat.LOG2 for sandbox group and capability SID
[2026-06-18T15:44:04.866765+00:00]    granting write ACE to C:\Users\black\NTUSER.DAT{...}.TM.blf for sandbox group and capability SID
...

The first temporary-profile sign-in failure occurred hours after this grant (2026-06-19 local time), then kept recurring on subsequent boots.

~/.codex/cap_sid retains the hive in its writable-roots ledger:

"writable_root_by_path": {
  "c:/users/black/ntuser.dat": "S-1-5-21-2736700426-2299951915-879265589-513510039",
  ...
}

icacls on the hive files showed (until manual cleanup):

C:\Users\black\NTUSER.DAT  <MACHINE>\CodexSandboxUsers:(M,DC)
                           S-1-5-21-2736700426-2299951915-879265589-513510039:(M,DC)
                           NT AUTHORITY\SYSTEM:(I)(F)
                           BUILTIN\Administrators:(I)(F)
                           <MACHINE>\<user>:(I)(F)

Reproduction conditions

1. Windows 11, [windows] sandbox = "elevated".
2. Trust C:\Users\<name> itself as a project (trust_level = "trusted"), e.g. by launching codex from the home directory.
3. Run a session that makes the sandbox set up write roots — sandbox.log shows per-file "granting write ACE" lines including the NTUSER.DAT family.
4. Reboot / sign out+in a few times → intermittent "User Profile Service failed the sign-in" with temporary profile fallback.

Observed mitigation in newer builds

Sandbox logs from command-runner 0.142.x show read-acl-only mode: applying read ACLs and setup refresh: processed 0 write roots (read roots delegated), so recent versions may no longer grant write ACEs. However, stale ACEs granted by earlier versions remain on the hive files and keep breaking profile loads until manually removed.

Requests

1. Exclude registry hive files (NTUSER.DAT*, ntuser.ini, *.blf, *.regtrans-ms) — and ideally the profile root's critical metadata generally — from any ACE grants, even when the home directory is the workspace root.
2. Provide a cleanup path (or setup-time repair) that removes hive ACEs left behind by earlier versions; the stale entries also persist in cap_sid.
3. Consider refusing to treat C:\Users\<name> itself as a writable workspace root, or at least warning loudly.

Manual cleanup that resolved it (for anyone else hit by this)

Remove the two non-inherited ACEs (CodexSandboxUsers + orphan capability SID) from NTUSER.DAT, ntuser.dat.LOG1/LOG2, ntuser.ini, and the .blf/.regtrans-ms files. Note icacls /remove may fail with error 1332 if the machine name contains non-ASCII characters; PowerShell's .NET ACL API (GetAccessControl → RemoveAccessRuleSpecific → SetAccessControl) works. Then remove the home directory's trust_level = "trusted" entry from config.toml.