Issue Station
Sign In
Tools hereToolbox

codex - 💡(How to fix) Fix Windows app sandbox setup fails with SetRemotePorts failed (HRESULT(0x80070057)) when building outbound firewall rule [3 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openai/codex#17686•Fetched 2026-04-14 05:41:17
View on GitHub
Comments
3
Participants
2
Timeline
8
Reactions
0
Author
SNComradeSNComrade
Participants
github-actions[bot]github-actions[bot]SNComradeSNComrade
Timeline (top)
labeled ×4commented ×3unlabeled ×1
RAW_BUFFERClick to expand / collapse

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)
  4. 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
  5. Inspect sandbox.log:
    • loopback UDP rule configured
    • loopback TCP rule configured with RemotePorts=*
    • loopback TCP rule configured with RemotePorts=1-65535
    • then SetRemotePorts failed
  6. 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

extent analysis

TL;DR

The likely fix is to skip calling SetRemotePorts() when remote_ports is unset or only call it when the rule protocol is TCP or UDP.

Guidance

  • Investigate the ensure_offline_outbound_block() function in codex-rs/windows-sandbox-rs/src/firewall.rs to understand how it handles remote_ports and NET_FW_IP_PROTOCOL_ANY.
  • Verify that the issue is resolved by checking the presence of the codex_sandbox_offline_block_outbound rule after applying the fix.
  • Consider adding a conditional statement to only call SetRemotePorts() when the rule protocol is TCP or UDP, to prevent Windows Firewall COM rejection.
  • Test the fix by reproducing the bug and checking the setup_error.json file for the absence of helper_firewall_rule_create_or_add_failed and SetRemotePorts failed errors.

Example

// Example of conditional statement to only call SetRemotePorts() when protocol is TCP or UDP
if protocol == "TCP" || protocol == "UDP" {
    SetRemotePorts(remote_ports);
}

Notes

The fix direction is based on the analysis of the local findings and the likely upstream code path. However, further investigation and testing are necessary to confirm the root cause and the effectiveness of the proposed fix.

Recommendation

Apply the workaround by skipping SetRemotePorts() when remote_ports is unset or only calling it when the rule protocol is TCP or UDP, as this is the most likely fix direction based on the provided information.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#permission error#memory optimization#batch processing#GPU compatibility#latency issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING