[permissions.workspace.filesystem] deny-globs documented in agent-approvals-security do not block reads in v0.130.0

[rsamuel-circle]

What version of Codex CLI is running?

codex-cli 0.130.0

What subscription do you have?

Pro (Enterprise)

Which model were you using?

gpt-5.5

What platform is your computer?

Darwin 25.4.0 arm64 arm

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

No response

What issue are you seeing?

The deny-glob feature documented at https://developers.openai.com/codex/agent-approvals-security#deny-reads-with-filesystem-profiles ("Deny reads with filesystem profiles") does not block reads of files matching the deny pattern. Tested in v0.130.0 across multiple variants — the deny silently no-ops in every case.

What steps can reproduce the bug?

Steps to reproduce

1. Configure ~/.codex/config.toml (or enterprise /etc/codex/requirements.toml) with a permission profile that denies .env:

   sandbox_mode = "workspace-write"
   default_permissions = "workspace"
   
   [features]
   hooks = true
   
   [permissions.workspace.filesystem]
   ":project_roots" = {
     "." = "write",
     "**/.env" = "none",
     "**/.env.*" = "none",
     "**/*.env" = "none"
   }
   glob_scan_max_depth = 3

2. Create a project with a .env file:

   mkdir -p ~/codex-permissions-repro
   cd ~/codex-permissions-repro
   echo "FAKE_KEY=test-value" > .env

3. Start codex in that directory:

   codex

4. In the codex TUI, prompt:

   run: bash -lc "cat .env; echo EXIT=$?"
   

What is the expected behavior?

Expected

The shell cat .env should be denied by the sandbox policy (**/.env matches), per the docs at https://developers.openai.com/codex/agent-approvals-security#deny-reads-with-filesystem-profiles which state:

"The sandbox policy evaluates globs for local macOS and Linux command execution."

Expected output: a sandbox denial / non-zero exit code.

Actual

FAKE_KEY=test-value
EXIT=0

The file is read successfully. The deny-glob is not enforced.

Additional information

No response

[viyatb-oai]

@rsamuel-circle thanks for reporting this - we are aware of it! #15977 adds support for it. We accidentally documented this a little early :)