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:
- Run Codex Desktop on native Windows.
- Use a projectless generated workspace or a normal local workspace.
- Keep the sandbox setting as
read only; the session starts and basic read-only shell commands work.
- Open Codex Desktop settings.
- Change sandbox mode from
read only to workspace write.
- 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
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.0What subscription do you have?
ChatGPT subscription with Codex access
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64What issue are you seeing?
In Codex Desktop settings, switching the sandbox mode from
read onlytoworkspace writemakes the app/session unstable and effectively unusable.The session starts successfully in
read-only. After changing the setting toworkspace 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:
sandbox_mode = "read-only".workspace write.PropertySetterNotSupportedInConstrainedLanguagewhen Codex tries to set console output encoding.code=1.Relevant log evidence
From
~\.codex\sandbox.log:The Desktop app log also repeatedly shows:
The app-server connection also logged a disconnect after the worker exited.
ACL observations
I inspected ACLs locally and anonymized the paths below:
CodexSandboxUsersonly read/execute access.Everyone:(I)(OI)(CI)(F)andAuthenticated Users:(I)(OI)(CI)(F), plus Codex-added DENY ACEs for capability SIDs.Everyone:(F)/Everyone:(OI)(CI)(IO)(F), plus Codex-added DENY ACEs.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:
read only; the session starts and basic read-only shell commands work.read onlytoworkspace write.Expected behavior
Switching from
read onlytoworkspace writein 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:
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 withcode=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
CreateProcessWithLogonW failed: 5#9062