Windows: sandbox_approval is unreachable from the UI, and request_permissions failures break the whole session

sandbox_approval is always false and the UI cannot change it

Every per-thread permission snapshot in <USERPROFILE>\.codex\.codex-global-state.json carries:

"approvalPolicy": { "granular": {
    "sandbox_approval": false, "rules": false, "skill_approval": false,
    "request_permissions": true, "mcp_elicitations": true } }

Across 25 threads: "sandbox_approval":true appears 0 times, false 25 times. The
global seed is {"kind":"agent-mode","agentMode":"granular"}.

The composer permission selector offers two options, and their descriptions match the permission
card text verbatim:

So "Request approval" is granular, and granular disables sandbox_approval by definition.
There is no UI path to a state that keeps the sandbox and allows an escalation request. A user who
wants "workspace-write plus on-demand escalation" cannot get it.

request_permissions failures break the entire session

A permission grant is applied by adding a write ACE for the sandbox account to the target path. The
helper runs non-elevated, so it cannot rewrite an ACL on a path it does not own. Observed twice
on paths owned by NT AUTHORITY\SYSTEM:

granting write ACE to C:\Users\Public for sandbox group and capability SID
write ACE grant failed on C:\Users\Public: SetNamedSecurityInfoW failed: 5
setup refresh completed with errors: ["write ACE failed on C:\\Users\\Public: SetNamedSecurityInfoW failed: 5"]
setup error: setup refresh had errors

write ACE check failed on C:\Windows\Temp: CreateFileW failed for C:\Windows\Temp
write ACE failed on C:\Windows\Temp: CreateFileW failed for C:\Windows\Temp
setup error: setup refresh had errors

After this, the turn's command channel is dead — even Get-Date returns:

exec_command failed: CreateProcess { message: "Rejected(\"Failed to create unified exec process:
helper_unknown_error: setup refresh had errors\")" }

Four consecutive failures within 7 seconds. The grant is scope: turn, so a new conversation
recovers; but within the affected turn the session is unusable, and the user has no way to clear
it.

Suggested fix

Fail fast and locally on an un-appliable permission grant instead of retrying it on every command
and taking the whole execution channel down. Ideally: detect at grant time that the target is not
writable by the helper, deny the request with reason, and leave the session healthy.

Start with the permission state in .codex\codex-global-state.json and trace the request_permissions grant and setup refresh flow on Windows. Reproduce a grant against a path owned by SYSTEM, then verify that an unappliable grant is rejected locally with a reason while subsequent commands in the turn remain usable.