AgentFixFind a fix
CodexOpen issueUpdated Sep 23, 2026

CoCreateInstance NetFwPolicy2 failed in Codex sandbox setup

Diagnose the Codex elevated Windows sandbox NetFwPolicy2 COM+ error without applying the unsafe junction used only for proof.

Exact error

Match the message before using the fix

helper_firewall_policy_access_failed: CoCreateInstance NetFwPolicy2 failed: HRESULT(0x80110474)The COM+ registry database detected a system error.

Quick answer

Start here

Match the full NetFwPolicy2 error and test whether PowerShell can create `HNetCfg.FwPolicy2`. If that succeeds while Codex fails, capture the sandbox helper's working directory and any literal `%systemroot%` path with ProcMon, then report it upstream. Do not create the junction shown in the issue: the reporter used it only to prove the path bug, not as a safe workaround.

Diagnosis

Why it happens

  • The source report observed `codex-windows-sandbox-setup.exe` looking for the COM+ catalog under a literal `%systemroot%` path relative to the working directory.
  • PowerShell could instantiate the same firewall policy COM object on that machine, which scopes the evidence to the helper process or its context.
  • Only one detailed upstream reproduction is available, so other HRESULTs or machines where the PowerShell COM test also fails need separate Windows diagnosis.

Safest first

Fixes, in order

01

Confirm the exact helper error and environment

Applies when: The elevated Windows sandbox fails before any model command runs

The page applies only to NetFwPolicy2 with HRESULT 0x80110474, not every CoCreateInstance failure.

  1. Copy the complete helper error, HRESULT, Codex version, Windows build, and active sandbox mode.
  2. Record whether a managed `requirements.toml` and `deny_read` rules are active.
  3. Do not include organization policy contents or protected paths in a public report.

Expected: The failure matches the documented NetFwPolicy2/COM+ branch exactly.

02

Test Windows firewall COM outside the helper

Applies when: You can run an ordinary PowerShell diagnostic on the same machine

The upstream report used this narrow comparison to show that Windows could create the COM object outside the Codex helper.

  1. Open PowerShell in the same user context.
  2. Create `HNetCfg.FwPolicy2` and read `CurrentProfileTypes`.
  3. If this also fails, stop and diagnose Windows COM/firewall health separately.
$fw = New-Object -ComObject HNetCfg.FwPolicy2
$fw.CurrentProfileTypes

Expected: PowerShell returns a firewall profile value; only the Codex helper remains failing.

03

Capture the literal-path evidence and update

Applies when: PowerShell succeeds but Codex still returns HRESULT 0x80110474

There is no confirmed user repair. A process trace can confirm whether your case matches the reported helper path-expansion bug.

  1. Update Codex through its official channel and reproduce once.
  2. Use ProcMon filtered to `codex-windows-sandbox-setup.exe` and the failure timestamp.
  3. Look for a path containing a literal `%systemroot%\Registration` under the project working directory.
  4. Share only a redacted trace summary with the upstream issue.

Expected: You either rule out the known branch or produce precise evidence for the open helper bug.

Verification

Prove the fix worked

  1. Start Codex with the same managed requirements and elevated sandbox settings.
  2. Confirm sandbox setup passes NetFwPolicy2 initialization.
  3. Run one harmless read-only command and verify no firewall-policy helper error is logged.

Escalation

If it still fails

  • Do not create a junction from a literal `%systemroot%` directory to `C:\Windows\Registration`; the source explicitly labels it diagnostic only.
  • Do not disable Windows Firewall or remove organization-managed requirements to hide the symptom.
  • If the PowerShell COM test fails too, use Windows support diagnostics because the available Codex evidence does not cover that branch.

Scope

Environment and version notes

  • The detailed report used Codex CLI 0.153.2 on Windows 11 build 26100 with an organization-managed account.
  • Its minimal reproduction used the elevated sandbox plus a managed requirements profile containing `deny_read`.
  • The upstream issue remained open when rechecked September 23, 2026.

Evidence

Sources

Source labels describe the evidence available on the checked date. A closed issue is not automatically a shipped fix.