Filesystem-only deny_read fails because elevated sandbox requires local firewall policy changes
Nobody has claimed this yet.
- 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
- Install Codex standalone CLI on Windows.
- Configure Windows sandbox mode as elevated.
- Use the minimal requirements.toml above.
- Ensure Windows reports a non-OK firewall local policy state:
PowerShell:
$fw = New-Object -ComObject HNetCfg.FwPolicy2
$fw.LocalPolicyModifyState
Observed value:
1 - Start Codex from the allowed workspace:
C:\Codex-Test - 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:
- Only require firewall policy changes when the active managed policy requires network/firewall restrictions, or
- 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
- 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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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