openai / openai/codex

Filesystem-only deny_read fails because elevated sandbox requires local firewall policy changes

Open
#44,499 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug CLI config sandbox windows-os
Dominant language
Rust
Stars
125k
Forks
19.4k
PR merge metrics
PR metrics pending

Description

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 Windows Terminal

Codex doctor report
Not available.
What issue are you seeing?

A managed requirements.toml with only a filesystem deny_read rule causes Codex to require Windows elevated sandbox provisioning. During provisioning,
Codex configures offline sandbox firewall rules and fails if local firewall policy modifications are not fully effective.
Minimal policy:
[permissions.filesystem]
deny_read = ["~/.ssh"]
There are no explicit firewall deny rules in the requirements.toml.
However, Codex fails with:
helper_firewall_policy_ineffective:
local firewall policy modifications will not take effect:
LocalPolicyModifyState=NET_FW_MODIFY_STATE(1)

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?
Steps to reproduce
  1. Install Codex standalone CLI on Windows.
  2. Configure Windows sandbox mode as elevated.
  3. Use the minimal requirements.toml above.
  4. Ensure Windows reports a non-OK firewall local policy state:
    PowerShell:
    $fw = New-Object -ComObject HNetCfg.FwPolicy2
    $fw.LocalPolicyModifyState
    Observed value:
    1
  5. Start Codex from the allowed workspace:
    C:\Codex-Test
  6. Observe that Codex fails during sandbox setup:
    helper_firewall_policy_ineffective:
    local firewall policy modifications will not take effect:
    LocalPolicyModifyState=NET_FW_MODIFY_STATE(1)
Why this is surprising

The active managed requirement is filesystem-only:
deny_read = ["~/.ssh"]
There are no explicit network/firewall deny rules in the managed requirements.
I expected Codex to enforce the filesystem deny_read rule without rejecting startup solely because local firewall policy changes are ineffective.

What is the expected behavior?
Expected behavior

Codex should either:

  1. Only require firewall policy changes when the active managed policy requires network/firewall restrictions, or
  2. Provide a separate managed setting that explicitly requires offline network isolation, so administrators can understand that filesystem deny_read implies firewall-policy requirements on Windows, or
  3. Produce documentation explaining that any deny_read rule on Windows requires the full elevated sandbox provisioning path, including effective local firewall policy modification support.
Actual behavior

A single filesystem deny_read rule triggers elevated sandbox provisioning, including offline sandbox firewall configuration.
The setup helper checks INetFwPolicy2::LocalPolicyModifyState and fails when Windows reports that local policy changes will not take effect:
helper_firewall_policy_ineffective:
local firewall policy modifications will not take effect:
LocalPolicyModifyState=NET_FW_MODIFY_STATE(1)

Relevant source behavior

In codex-rs/windows-sandbox-rs/src/bin/setup_main/win.rs, sandbox provisioning calls configure_offline_sandbox_network(...), which configures firewall
rules for the offline sandbox user.
In codex-rs/windows-sandbox-rs/src/bin/setup_main/win/firewall.rs, the helper calls ensure_local_policy_rules_take_effect(...) before applying firewall
rules and fails if LocalPolicyModifyState is not NET_FW_MODIFY_STATE_OK.

Additional information
Additional diagnostics

On the same machine, basic NetFwPolicy2 operations work:
$fw = New-Object -ComObject HNetCfg.FwPolicy2
$fw.CurrentProfileTypes
$fw.LocalPolicyModifyState
Result:
CurrentProfileTypes = 5
LocalPolicyModifyState = 1
Creating and removing a firewall rule through NetFwPolicy2 COM also works, but Codex still rejects the policy state because LocalPolicyModifyState is not
OK.

Request

Please clarify whether filesystem deny_read is intentionally coupled to full offline network/firewall sandbox provisioning on Windows.
If this is intentional, it would be helpful to document that Windows deny_read requires LocalPolicyModifyState == NET_FW_MODIFY_STATE_OK.
If not intentional, please consider making the sandbox checks more granular so filesystem-only deny_read policies do not fail solely because local firewall policy modifications are ineffective.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in codex-rs/windows-sandbox-rs/src/bin/setup_main/win.rs, then read win/firewall.rs, focusing on configure_offline_sandbox_network and ensure_local_policy_rules_take_effect. Reproduce with the supplied requirements.toml and PowerShell LocalPolicyModifyState check; done means the project has a confirmed policy on whether filesystem-only deny_read requires firewall provisioning, reflected in the relevant behavior or documentation.

Written by the indexing model from the issue text.

Assessment

Tech stack
powershell, rust
Domain
networking, operating-systems, security
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
52/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.