codex - 💡(How to fix) Fix Windows Desktop: switching sandbox from read-only to workspace-write crashes UI after world-writable ACL scan [1 comments, 2 participants]

What version of the Codex App are you using (From About Codex dialog)?

Microsoft Store package version observed from local log paths:

26.422.1952.0

What subscription do you have?

ChatGPT subscription with Codex access

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

In Codex Desktop settings, switching the sandbox mode from read only to workspace write makes the app/session unstable and effectively unusable.

The session starts successfully in read-only. After changing the setting to workspace write, Codex appears to run Windows sandbox ACL setup / audit logic. The app then logs repeated React error boundary failures and the worker exits.

Important local symptoms:

• Current session comes back as sandbox_mode = "read-only".
• The Desktop settings UI can trigger an error loop when switching to workspace write.
• PowerShell commands still run, but each command reports PropertySetterNotSupportedInConstrainedLanguage when Codex tries to set console output encoding.
• The worker later exits with code=1.

Relevant log evidence

From ~\.codex\sandbox.log:

AUDIT: world-writable scan FAILED; cwd="<WORKSPACE>"; checked=334; duration_ms=31; flagged:
 - <WORKSPACE>
 - <FLAGGED_DIR_1>
 - <FLAGGED_DIR_2>
AUDIT: applied capability deny ACE to <WORKSPACE>
AUDIT: applied capability deny ACE to <FLAGGED_DIR_1>
AUDIT: applied capability deny ACE to <FLAGGED_DIR_2>

The Desktop app log also repeatedly shows:

error boundary ... errorMessage="Minified React error #185 ..." ... name=LocalConversationPage
error boundary ... errorMessage="Minified React error #185 ..." ... name=AppRoutes
warning [worker-manager] Worker exited code=1

The app-server connection also logged a disconnect after the worker exited.

ACL observations

I inspected ACLs locally and anonymized the paths below:

• The current projectless Codex workspace grants CodexSandboxUsers only read/execute access.
• One flagged workspace-like directory had broad inherited permissions such as Everyone:(I)(OI)(CI)(F) and Authenticated Users:(I)(OI)(CI)(F), plus Codex-added DENY ACEs for capability SIDs.
• Another flagged root-level directory had Everyone:(F) / Everyone:(OI)(CI)(IO)(F), plus Codex-added DENY ACEs.
• One previously flagged directory no longer existed by the time I inspected it.

This looks like the Desktop app is detecting world-writable paths and attempting to repair or deny them, but the sandbox mode switch path leaves the Desktop UI / worker in a broken state.

Steps to reproduce

I do not yet have a minimal clean-machine repro, but this is the observed flow:

1. Run Codex Desktop on native Windows.
2. Use a projectless generated workspace or a normal local workspace.
3. Keep the sandbox setting as read only; the session starts and basic read-only shell commands work.
4. Open Codex Desktop settings.
5. Change sandbox mode from read only to workspace write.
6. Observe the app/session become unstable or fail, with the logs above.

Expected behavior

Switching from read only to workspace write in Codex Desktop settings should not crash the UI, trigger a React update loop, or kill the worker.

If the Windows sandbox detects world-writable paths, Codex should either:

• show a clear actionable diagnostic and refuse the mode switch safely, or
• complete ACL repair without destabilizing the Desktop app/session.

Actual behavior

The mode switch appears to hit Windows sandbox ACL audit/repair logic, then the Desktop UI repeatedly logs Minified React error #185, and the worker exits with code=1.

Privacy note

I intentionally redacted local usernames, exact home-directory paths, and nonessential local directory names from this report. I did not attach raw auth.json, full logs, or unredacted local paths.

Possibly related

• #17179
• #17901
• #9062
• #18558