Windows elevated sandbox re-arms WFP firewall on nearly every command (offline ports keep changing), causing constant UAC prompts

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

Version 26.623.141536 • Released 7 июл. 2026 г.

What subscription do you have?

Pro plan $200/mo

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Summary

With the elevated Windows native sandbox ([windows] sandbox = "elevated", sandbox_mode = "workspace-write"), Codex re-runs the elevated firewall (WFP) setup hundreds of times per day instead of once per session. Each re-arm needs elevation, producing a near-constant stream of UAC prompts during normal work.

Root cause: the offline sandbox's loopback ports keep changing and the stored state is frequently empty, so Codex sees "offline firewall settings changed" on almost every network-touching command and re-provisions the WFP filters (an admin operation).

This is distinct from the installer-detection / os error 740 issues (#26619, #26477, #24050): the asInvoker manifest is present in the v0.143.0 codex-windows-sandbox-setup.exe and setup succeeds (errors=[]). This is not forced elevation from the filename — it is intentional re-elevation happening far too often.

Environment / config

• codex-cli 0.143.0, local administrator account (UAC = consent prompt)
• codex-windows-sandbox-setup.exe manifest = requestedExecutionLevel level="asInvoker"

sandbox_mode = "workspace-write"
[windows]
sandbox = "elevated"
[sandbox_workspace_write]
network_access = true

### What steps can reproduce the bug?

On Windows, sandbox_mode = "workspace-write" + [windows] sandbox = "elevated".
Run a normal session and let the agent execute several commands that run in the sandbox (anything that touches the network path — read-only commands like git status do not trigger it).
Observe repeated UAC prompts for codex-windows-sandbox-setup.exe.

### What is the expected behavior?

The elevated firewall/WFP setup should run at most once per session (or be reused via a persistent elevated broker), not on nearly every command. Equivalently, the offline sandbox should use stable loopback ports per session and persist its stored state so it does not perpetually see "settings changed".

Suggested fixes:
- Keep the chosen offline ports stable for the session and persist `stored_ports` so re-provisioning is not triggered on every command.
- Or hold a persistent elevated helper/broker so a single UAC covers subsequent re-arms.

### Additional information

Workaround: the only setting that reliably stops the UAC storm is disabling the sandbox entirely — `sandbox_mode = "danger-full-access"` (GUI: Settings → Configuration → Sandbox settings → Full access), which removes all OS isolation.

I could not cleanly test `[windows] sandbox = "unelevated"` as a middle ground:
- The desktop app owns `config.toml` and overwrites manual edits with its in-memory value on change/close, so editing `[windows] sandbox` in the file does not stick while the app runs.
- The GUI dropdown only exposes read-only / workspace-write / full-access; it does not expose the elevated/unelevated toggle.

Not a duplicate of #26619 / #26477 (installer-detection / `os error 740`), which are closed and about the setup helper being *forced* to elevate. Here elevation *succeeds* (`errors=[]`) but is invoked constantly due to changing offline firewall ports.

Related: #23712 (unelevated still launches elevated helper), #30445 (setup marker ACL).