Windows sandbox setup fails because COM+ catalog path uses literal %systemroot% relative to current directory

What version of Codex CLI is running?

codex-cli 0.153.2

What subscription do you have?

organization-managed account

Which model were you using?

Not model-specific. The failure happens during Windows sandbox setup before the model interaction starts

What platform is your computer?

Windows 11 x64 OS build: 10.0.26100

What terminal emulator and version are you using (if applicable)?

Windows PowerShell 5.1 in standard console

Codex doctor report

Not available

What issue are you seeing?

When Codex starts with Windows elevated sandbox and a managed requirements.toml containing deny_read rules, the Windows sandbox setup helper fails while
initializing NetFwPolicy2:
Error:
helper_firewall_policy_access_failed:
CoCreateInstance NetFwPolicy2 failed:
HRESULT(0x80110474)
"The COM+ registry database detected a system error."
Using ProcMon, I observed that codex-windows-sandbox-setup.exe tries to access the COM+ catalog under a non-expanded %systemroot% path relative to the
current working directory:
C:\Codex-Test%systemroot%\Registration\R000000000013.clb
The actual COM+ catalog file exists under:
C:\Windows\Registration\R000000000013.clb
This suggests that the helper process or its COM initialization context is causing %systemroot% to be treated as a literal relative path instead of being
expanded to C:\Windows.

Minimal requirements.toml

default_permissions = "test"
[allowed_permission_profiles]
test = true
[permissions.filesystem]
deny_read = ["~/.ssh"]
[permissions.test]
description = "Minimal repro"
[permissions.test.workspace_roots]
"C:/Codex-Test" = true
[permissions.test.filesystem]
":root" = "read"
[permissions.test.filesystem."C:/Codex-Test"]
"." = "write"
[permissions.test.filesystem.":tmpdir"]
"." = "write"
[permissions.test.network]
enabled = true
allow_local_binding = true

What steps can reproduce the bug?

1. Install Codex standalone CLI on Windows.
2. Configure Codex to use Windows elevated sandbox.
3. Create the minimal requirements.toml above.
4. Start Codex from a working directory such as:
   C:\Codex-Test
5. Observe that Codex fails during sandbox setup with:
   helper_firewall_policy_access_failed:
   CoCreateInstance NetFwPolicy2 failed:
   HRESULT(0x80110474)
6. Capture with ProcMon filtered to codex-windows-sandbox-setup.exe.
7. Observe access attempts to a path like:
   C:\Codex-Test%systemroot%\Registration\R000000000013.clb

What is the expected behavior?

codex-windows-sandbox-setup.exe should initialize NetFwPolicy2 without causing COM+ to look for %systemroot%\Registration relative to the current working
directory.
The helper should either:

• run with a safe explicit working directory,
• ensure required environment variables are available and expanded correctly,
• or otherwise initialize COM in a way that does not produce relative literal %systemroot% catalog lookups.

Diagnostic workaround used only to confirm the path issue

Creating a temporary junction from the literal path to the real COM+ catalog directory changes the error:
PowerShell:
New-Item -ItemType Directory -Path "C:\Codex-Test%systemroot%" -Force
New-Item -ItemType Junction -Path 'C:\Codex-Test%systemroot%\Registration' -Target 'C:\Windows\Registration'
After this, Codex no longer fails with the original CoCreateInstance/COM+ registry database error. It proceeds to a later firewall policy state check.
This was only used as a diagnostic test, not as a proposed workaround.

Actual behavior

The helper fails at NetFwPolicy2 COM initialization with:
helper_firewall_policy_access_failed:
CoCreateInstance NetFwPolicy2 failed:
HRESULT(0x80110474)
ProcMon shows a literal %systemroot% path under the current working directory.

Additional information

PowerShell can initialize NetFwPolicy2 successfully on the same machine:
$fw = New-Object -ComObject HNetCfg.FwPolicy2
$fw.CurrentProfileTypes
COMAdmin catalog access also works:
$catalog = New-Object -ComObject COMAdmin.COMAdminCatalog
$apps = $catalog.GetCollection("Applications")
$apps.Populate()
$apps.Count
So the issue appears specific to the sandbox setup helper process/context.

Start with the codex-windows-sandbox-setup.exe entry point and investigate its NetFwPolicy2 COM initialization under a working directory such as C:\Codex-Test. Reproduce with the minimal requirements.toml and ProcMon, comparing the literal %systemroot% lookup with the successful PowerShell COM initialization. Done means the helper initializes NetFwPolicy2 without a relative literal %systemroot% catalog path.