[Windows Desktop] Sandbox refresh recursively processes writable roots for 1–2 minutes before every tool call

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

26.715.8383.0 Bundled command runner: codex-command-runner-0.145.0-alpha.27.exe

What subscription do you have?

plus

What platform is your computer?

_No response_

What issue are you seeing?

Every sandboxed shell or apply_patch call spends approximately 1–2 minutes running codex-windows-sandbox-setup.exe before the actual command can execute.

Even a command that does not access the repository hangs:

Write-Output "sandbox-ok"

The same command completes immediately with external/escalated execution.
The workspace is a large Unity repository containing generated directories such as Library, Temp, Logs, and obj. These directories are Git-ignored, but they are still under the configured writable root.
The sandbox log indicates that Codex repeatedly refreshes ACLs for all writable roots. The refresh eventually reports errors=[], but takes up to two minutes. If the tool invocation is cancelled or times out while waiting, the command later appears as FAILURE ... exit code 1.
Restarting Codex Desktop does not resolve the issue. A new invocation triggers another full setup refresh.
This makes normal sandboxed reading, editing, and apply_patch effectively unusable.

### What steps can reproduce the bug?

1.Open Codex Desktop on Windows.
2.Open a large Unity repository as the workspace.
3.Use workspace-write sandbox mode.
4.Ask Codex to run:
Write-Output "sandbox-ok"
5.Observe that no output is returned within the normal command timeout.
6.Check:%USERPROFILE%\.codex\.sandbox\sandbox.YYYY-MM-DD.log
7.Observe setup refresh: spawning ... codex-windows-sandbox-setup.exe.
8.Wait approximately 1–2 minutes.
9.Observe setup refresh: processed 3 write roots ... errors=[].
10.Run another minimal command and observe that another setup refresh is started.

The issue also occurs when the command working directory is C:\, because Codex still refreshes the configured workspace writable root.

### What is the expected behavior?

Sandbox ACL setup should be cached or incremental.
Once the workspace root has valid inherited sandbox permissions, a simple command should start immediately. Git-ignored generated directories should not cause a recursive ACL refresh before every tool invocation.
Cancelling one tool invocation should also terminate or clean up its setup and child processes.

### Additional information

The workspace ACL already grants Modify access to CodexSandboxUsers.
Multiple explicit sandbox/capability SID ACEs have accumulated on the workspace root.
External execution works normally.
PowerShell itself is healthy.
The failure happens before the target command executes.
Repeated failed/cancelled calls can leave Git metadata processes such as git status, git config, and git remote -v running after their parent process exits.
The issue appears to be in the Windows sandbox setup/ACL refresh lifecycle rather than in the repository or the target command.