codex - 💡(How to fix) Fix Sandbox setup infinite loop on Windows 11 Home: SetNamedSecurityInfoW fails (error 87) on Google Drive (FAT32) trusted projects + frontend/backend version skew (26.515 vs 26.513)

What version of the Codex App are you using?

• Microsoft Store package: OpenAI.Codex 26.513.4821.0 (x64)
• Bundled runtime found in ~/.cache/codex-runtimes/codex-primary-runtime/runtime.json: 26.515.10909 (newer than MSIX backend)

What subscription do you have?

ChatGPT subscription with Codex access

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64 (Windows 11 Home)

What issue are you seeing?

The Codex Desktop app gets stuck in a "Configure agent sandbox to continue" (続行するにはエージェントサンドボックスを設定してください) loop. Sending any chat message produces a "Could not send message" dialog. Clicking the "Configure" (設定する) button retries sandbox setup but it never succeeds.

Two underlying problems compound:

Problem 1: Sandbox ACL setup fails on Google Drive (G:) trusted projects

codex-windows-sandbox-setup.exe tries to grant a read ACE to the sandbox group on every [projects.*] entry marked trust_level = "trusted". For paths under G:\ (Google Drive for Desktop with "Stream files" mode, version 125.0.0.0), this fails:

[2026-05-17T...] grant read ACE failed on G:\マイドライブ\015_外部委託先との業務委託契約\オフィス110（コピー機リース） 
for sandbox_group: SetNamedSecurityInfoW failed: 87
[2026-05-17T...] read ACL run completed with errors: [...]
[2026-05-17T...] setup error: read ACL run had errors

Error 87 is ERROR_INVALID_PARAMETER. The cause is that G:\ is presented by Google Drive File Stream as FAT32 (DriveFormat: FAT32 from [System.IO.DriveInfo]), which does not support NTFS security descriptors at all. So SetNamedSecurityInfoW rightfully rejects the call.

The single ACL failure causes the sandbox to be marked unhealthy globally, even when the rest of the trusted projects are on legitimate NTFS volumes.

Notably, older versions of the Codex desktop app worked fine with the exact same Google Drive setup — failures were logged but did not block sandbox initialization. A recent change made any ACL grant failure fatal.

Problem 2: Frontend/backend API version skew prevents recovery

The Electron frontend (using runtime 26.515.10909 from the runtime cache) calls IPC method windowsSandbox/readiness. The MSIX backend (codex-app-server.exe from MSIX 26.513.4821.0) responds:

error [electron-message-handler] Failed to load Windows sandbox readiness 
error={"code":-32600,"message":"Invalid request: unknown variant `windowsSandbox/readiness`, 
expected one of `initialize`, `thread/start`, ..., `windowsSandbox/setupStart`, ...

The backend only knows windowsSandbox/setupStart, not readiness. Because the frontend can't determine whether sandbox is ready, it conservatively shows the "Configure sandbox" banner and blocks turn/start for every message.

Other newer-frontend methods rejected by the older backend in the same logs:

• hooks/list → "unknown variant hooks/list"
• experimentalFeature/enablement/set with auth_elicitation → "invalid feature enablement auth_elicitation"

This means even if a user works around Problem 1 by removing all G:\ trusted projects, the readiness check still fails on the unknown method, and the banner persists.

What steps can reproduce the bug?

1. Install Codex Desktop from Microsoft Store on Windows 11 Home (OpenAI.Codex 26.513.4821.0)
2. Have Google Drive for Desktop installed in "Stream files" mode (so G:\ exists as FAT32)
3. Add any folder under G:\マイドライブ\... or G:\共有ドライブ\... as a trusted project (trust_level = "trusted" in ~/.codex/config.toml)
4. Have the runtime auto-update to 26.515.10909 (downloaded to ~/.cache/codex-runtimes/codex-primary-runtime/)
5. Launch Codex and try to send a message in any conversation

Observed: ~/.codex/.sandbox/setup_error.json contains:

{
  "code": "helper_unknown_error",
  "message": "read ACL run had errors"
}

and ~/.codex/.sandbox/sandbox.log shows repeated SetNamedSecurityInfoW failed: 87 on G:\ paths. The "Configure sandbox" banner persists. Clicking "Configure" re-runs setup which fails the same way. Setting sandbox_mode = "danger-full-access" in config.toml does not bypass it because the frontend's windowsSandbox/readiness call to the backend fails with unknown variant, so the frontend never sees the sandbox as ready regardless of mode.

What is the expected behavior?

1. ACL failures on unsupported filesystems should be non-fatal. Either:
   • Skip ACL grants for paths on FAT/exFAT/UDF/FUSE filesystems and log a warning, OR
   • Provide a documented escape hatch (e.g. sandbox.skip_acl_for_drives = ["G:"] or sandbox.continue_on_acl_error = true in config.toml).
2. Frontend and backend should ship at compatible API versions. Either:
   • Pin the runtime version to match the MSIX backend version, OR
   • Have the frontend tolerate unknown variant on optional readiness methods and fall back to a known-good behavior (e.g. assume ready when sandbox_mode = "danger-full-access").
3. sandbox_mode = "danger-full-access" in config.toml should fully bypass ACL setup as documented in the binary help text ("No filesystem sandboxing - all commands are permitted").

Additional information

• Workaround attempted: removing all G:\ projects from config.toml and setting sandbox_mode = "danger-full-access" — partially works (no ACL errors logged) but windowsSandbox/readiness call still fails on the backend so the banner persists.
• Workaround attempted: deleting ~/.cache/codex-runtimes to force a fresh runtime download — same 26.515.10909 is downloaded again, so the version skew returns.
• Related issues:
  • #17901 — same SetNamedSecurityInfoW API but failing with error 5 (ACCESS_DENIED) on WindowsApps
  • #17612 — sandbox ACL failure causing child process timeout
  • #22044 — restricted-token sandbox issues with --add-dir
  • #21364 — "unknown variant" in Windows sandbox config (similar API mismatch pattern)
• Environment:
  • Windows 11 Home 10.0.26200
  • Google Drive File Stream 125.0.0.0
  • G:\ reports as DriveType: Fixed, DriveFormat: FAT32
  • PowerShell: Set-Acl G:\マイドライブ fails with "Attempted to perform an unauthorized operation"