Windows app sandbox setup fails with SetRemotePorts failed (HRESULT(0x80070057)) when building outbound firewall rule

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

26.409.1734.0

What subscription do you have?

PRO

What platform is your computer?

Microsoft Windows 11 Pro for Workstations
10.0.26200 Build 26200

What issue are you seeing?

On Windows, the Codex App appears to fail during elevated sandbox firewall setup with:

• helper_firewall_rule_create_or_add_failed
• SetRemotePorts failed: HRESULT(0x80070057)

After investigating locally, the strongest current reading is that the Windows sandbox helper is likely building the non-loopback outbound firewall rule with:

• NET_FW_IP_PROTOCOL_ANY
• remote_ports: None

and then still calling:

• SetRemotePorts("*")

on that rule.

Windows Firewall COM appears to reject RemotePorts on an ANY-protocol rule with HRESULT(0x80070057).

This looks separate from the earlier proxy-linked SetRemoteAddresses issue and separate from the later WindowsApps ACL failure path.

What steps can reproduce the bug?

Local repro / evidence path:

1. On Windows, launch the Codex App.
2. Trigger a flow that causes elevated Windows sandbox setup to run (windowsSandbox/setupStart), for example a first auth/setup path or a tool-execution path that refreshes sandbox setup.
3. Observe a fresh setup_error.json with:

• helper_firewall_rule_create_or_add_failed
• SetRemotePorts failed: HRESULT(0x80070057)

1. Inspect firewall rules after the failure:

• codex_sandbox_offline_block_loopback_udp is present
• codex_sandbox_offline_block_loopback_tcp is present
• codex_sandbox_offline_block_outbound is absent

1. Inspect sandbox.log:

• loopback UDP rule configured
• loopback TCP rule configured with RemotePorts=*
• loopback TCP rule configured with RemotePorts=1-65535
• then SetRemotePorts failed

1. Reproduce the Windows Firewall COM behavior in-memory with HNetCfg.FWRule:

• Protocol=Any + RemotePorts=* -> fails
• Protocol=Any + RemotePorts=1-65535 -> fails
• Protocol=TCP + RemotePorts=* -> succeeds
• Protocol=TCP + RemotePorts=1-65535 -> succeeds

What is the expected behavior?

Elevated Windows sandbox setup should complete without failing at firewall-rule creation, and the non-loopback outbound sandbox block rule should be created successfully.

The helper should not call SetRemotePorts() on a rule/protocol combination that Windows Firewall COM rejects.

Additional information

Relevant local findings:

• No proxy env vars were set at User / Machine / Process scope for:
• HTTP_PROXY
• HTTPS_PROXY
• NO_PROXY
• ALL_PROXY
• netsh winhttp show proxy reported:
• Direct access (no proxy server)
• The loopback TCP sandbox rule persisted with:
• loopback remote addresses
• RemotePorts=1-65535
• The non-loopback outbound sandbox rule was not persisted

Likely upstream code path:

• codex-rs/windows-sandbox-rs/src/firewall.rs
• ensure_offline_outbound_block() uses:
• NET_FW_IP_PROTOCOL_ANY
• remote_ports: None
• configure_rule() resolves unset ports to "*" and still calls:
• SetRemotePorts(...)

That combination appears to match the local failure exactly.

Likely fix direction:

• skip SetRemotePorts() when remote_ports is unset

or:

• only call SetRemotePorts() when the rule protocol is TCP or UDP

Separate note:

• I believe this firewall bug is separate from the no-main-window relaunch issue
• I also expect the WindowsApps ACL issue may become the next blocker after the firewall path is fixed