›_ Codex Issues
Codex Issues / #34313

Windows elevated sandbox trusts stale setup marker after firewall setup failure and skips reprovisioning

Open 💬 0 comments Opened Jul 20, 2026 by cloversx

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

ChatGPT desktop app: 26.715.31925

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.22631.0 x64

What issue are you seeing?

An earlier elevated Windows sandbox setup failed while creating Windows Firewall rules:

helper_firewall_rule_create_or_add_failed:
SetRemoteAddresses failed:
HRESULT(0x80070057)

However, the existing version-5 setup_marker.json and sandbox user credentials remained.

After reinstalling/updating to ChatGPT desktop app version 26.715.31925, the app accepted the existing sandbox setup state and ran commands as:

<REDACTED-PC>\codexsandboxoffline

The configuration was:

[windows]
sandbox = "elevated"

However, no Codex sandbox firewall rules were present in the Windows Firewall ActiveStore.

The following expected rules were absent:

codex_sandbox_offline_block_loopback_udp
codex_sandbox_offline_block_loopback_tcp
codex_sandbox_offline_block_outbound

The app did not request full Windows sandbox setup while the old version-5 marker remained.

Renaming setup_marker.json caused the app to request Windows setup again. After approving UAC, setup completed successfully and created the expected firewall rules and 12 WFP filters.

Renaming the marker was the recovery action, not the cause of the bug.

What steps can reproduce the bug?

This issue depends on a partially failed earlier Windows sandbox setup and cannot be reproduced with a standalone code snippet alone.

Starting state

  1. Elevated Windows sandbox setup fails during firewall provisioning.
  2. The setup log contains:
helper_firewall_rule_create_or_add_failed:
SetRemoteAddresses failed:
HRESULT(0x80070057)
  1. A version-5 setup_marker.json and sandbox user credentials remain.
  2. The expected codex_sandbox_* firewall rules are absent.

Reproduction

  1. Leave the existing version-5 setup_marker.json and sandbox credentials in place.
  2. Install or update to ChatGPT desktop app version 26.715.31925.
  3. Ensure the configuration contains:
[windows]
sandbox = "elevated"
  1. Start the app normally.
  2. Run:
whoami
  1. Observe that commands run as:
<REDACTED-PC>\codexsandboxoffline
  1. Open an administrator PowerShell window and run:
Get-NetFirewallRule -PolicyStore ActiveStore |
    Where-Object {
        $_.Name -like "codex_sandbox_*" -or
        $_.DisplayName -match "Codex.*Sandbox"
    } |
    Select-Object Name, DisplayName, Enabled, Direction, Action
  1. Observe that no Codex sandbox firewall rules are returned.
  2. Observe that the app does not request full Windows sandbox setup.

Recovery demonstrating the stale-marker behavior

  1. Fully exit the ChatGPT desktop app.
  2. Rename:
%USERPROFILE%\.codex\.sandbox\setup_marker.json
  1. Do not delete the sandbox users or .sandbox-secrets.
  2. Start the app normally.
  3. The app now requests completion of Windows setup.
  4. Approve the UAC prompt.
  5. Setup completes successfully.
  6. The expected firewall rules and WFP filters are created.

What is the expected behavior?

If Windows firewall or WFP provisioning fails, the elevated sandbox setup should not remain trusted as complete.

The app should do one of the following:

  • remove or invalidate the setup marker after a failed provisioning step;
  • validate the required firewall and WFP enforcement state on later startup;
  • request repair or full reprovisioning when the expected enforcement state is missing.

A stale setup marker should not cause the app to skip full setup while the expected offline sandbox firewall rules are absent.

Additional information

Environment

  • ChatGPT desktop app: 26.715.31925
  • Subscription: Plus
  • Windows 11 Pro
  • Version: 23H2
  • OS build: 22631.6199
  • Architecture: x64

Old marker

{
  "version": 5,
  "offline_username": "CodexSandboxOffline",
  "online_username": "CodexSandboxOnline",
  "created_at": "2026-04-02T21:22:34.896180400+00:00",
  "proxy_ports": [],
  "allow_local_binding": false,
  "read_roots": [],
  "write_roots": []
}

New marker after successful reprovisioning

{
  "version": 5,
  "offline_username": "CodexSandboxOffline",
  "online_username": "CodexSandboxOnline",
  "created_at": "2026-07-19T06:54:26.061858600+00:00",
  "proxy_ports": [],
  "allow_local_binding": false,
  "read_roots": [],
  "write_roots": []
}

Firewall rules after repair

codex_sandbox_offline_block_loopback_udp  Enabled=True  Direction=Outbound  Action=Block
codex_sandbox_offline_block_loopback_tcp  Enabled=True  Direction=Outbound  Action=Block
codex_sandbox_offline_block_outbound      Enabled=True  Direction=Outbound  Action=Block

Successful setup log

WFP setup succeeded for CodexSandboxOffline with 12 installed filters
setup binary completed

This report was previously reviewed through the OpenAI Bugcrowd program and classified as a functional bug rather than an in-scope security vulnerability.

I did not test outbound connectivity before repair and did not directly inspect the pre-repair WFP filter state. I am therefore reporting this as a setup validation and recovery bug, not claiming confirmed exploitability.

The PC name, normal Windows username, and full SID have been redacted.

View original on GitHub ↗