Windows Desktop: elevated sandbox fails with "requires effective :root read access" on every thread (new and existing); unelevated, admin relaunch, app repair, and app reset all fail to fix it

Description

After the latest ChatGPT Desktop update, every chat (new threads and resuming existing ones) fails immediately with:

Fatal error: Failed to initialize session: failed to load AGENTS.md instructions for environment `local`:
fs sandbox helper failed with status exit code: 1: windows sandbox failed: elevated Windows sandbox requires effective `:root` read access

This affects 100% of sessions — the app is completely unusable for local work.

Environment

• OS: Windows 11 (10.0.26200)
• App: ChatGPT Desktop, package OpenAI.ChatGPT-Desktop_1.2026.133.0_x64 (MSIX/Store-installed)
• App build: 26.911.61220 (from config BROWSER_USE_CODEX_APP_VERSION)
• Codex CLI bundled/installed alongside: codex-cli 0.139.0 (update to 0.154.0 available but not yet applied)
• [windows] sandbox = "elevated" in config.toml

What I already tried (none fixed it)

1. Switched [windows] sandbox to "unelevated" → different, more specific failure:

   windows unelevated restricted-token sandbox cannot enforce split filesystem read restrictions directly; refusing to run unsandboxed
   

   This is because my default_permissions = "shift_ai_safe" profile uses deny-read overlays (e.g. .env, .ssh/** = "none" while other paths are readable/writable), which the unelevated restricted-token backend can't enforce. Reverted to "elevated".

2. Relaunched the app via "Run as administrator" → identical original error.

3. Windows Settings → Apps → ChatGPT → Repair → identical original error.

4. Windows Settings → Apps → ChatGPT → Reset → app data was reset per the OS, but the app reopened already logged in with all previous state intact (project/thread list, etc.) — meaning the actual persistent state lives outside the MSIX package container (in %USERPROFILE%\.codex\) and "Reset" doesn't touch it. Error unchanged.

Diagnostic evidence from %USERPROFILE%\.codex\.sandbox\

• setup_marker.json shows the sandbox principals were created back on 2026-05-24, but their granted roots are empty:

  {
    "version": 5,
    "offline_username": "CodexSandboxOffline",
    "online_username": "CodexSandboxOnline",
    "created_at": "2026-05-24T10:53:14.158560+00:00",
    "proxy_ports": [],
    "allow_local_binding": false,
    "read_roots": [],
    "write_roots": []
  }
  

• deny_read_acl_state.json shows no registered principals:

  { "principals": {} }
  

• sandbox.<today>.log shows --codex-run-as-fs-helper being spawned and retried in a tight ~2s loop, presumably failing and retrying, for every attempted session.

This looks like the sandbox reprovisioning step (populating read_roots/write_roots and the deny-read ACL principal registry) silently failed after the update, and there's no user-facing repair path that re-triggers it — elevated relaunch, OS-level app repair, and OS-level app reset all leave this state untouched.

Related issues (same bug family, not exact duplicates)

• #15165 – elevated sandbox does not recursively grant usable ACLs to existing workspace files
• #46062 – sandbox setup fails applying deny ACE to a repo directory
• #31620 – setup fails on NTFS ACL / SetNamedSecurityInfoW error 5, falls back to unsandboxed PowerShell
• #29867 – workspace left owned by CodexSandboxOnline, setup refresh fails

Ask

• A supported way to force full sandbox re-provisioning (recreate/repopulate read_roots/write_roots and the deny-read ACL registry) without manually touching files under .codex\.sandbox\, since neither app Repair nor Reset reaches this state.

Start by inspecting the sandbox state under %USERPROFILE%\.codex\.sandbox\, especially setup_marker.json, deny_read_acl_state.json, and the sandbox log, alongside the [windows] sandbox setting in config.toml. Trace how sandbox provisioning is triggered and determine why the roots and deny-read principals remain empty after app repair or reset. Done means a supported reprovisioning path restores the required state and local sessions initialize successfully.