Managed requirements deny_read changes Git permission path; git prompt rule cannot restore normal workspace Git writes

What issue are you seeing?

With a managed /etc/codex/requirements.toml that contains an unrelated permissions.filesystem.deny_read entry and a rules.prefix_rules entry for git with decision = "prompt", Codex does not successfully complete ordinary user-requested Git workflows such as git add plus git commit in a disposable repository.

The observed behavior suggests Codex uses different permission evaluation paths depending on whether managed filesystem restrictions such as permissions.filesystem.deny_read are present. Once that path is active, normal Git metadata writes can be blocked by the sandbox. A rules.prefix_rules prompt for git routes the command into approval review, but after the initial sandbox block it does not get the operation back onto the permission path that allows normal current-worktree Git metadata writes.

What steps can reproduce the bug?

Minimal Repro

This repro intentionally omits guardian_policy_config; the issue appears before Guardian policy text contributes meaningfully.

/etc/codex/requirements.toml:

allowed_approval_policies = ["on-request", "never"]
allowed_approvals_reviewers = ["auto_review"]
allowed_sandbox_modes = ["read-only", "workspace-write"]

[permissions.filesystem]
deny_read = [
  "/System/Library/Keychains/**",
]

[rules]
prefix_rules = [
  { pattern = [{ any_of = ["git", "/usr/bin/git", "/opt/homebrew/bin/git", "/usr/local/bin/git"] }], decision = "prompt", justification = "Repro: route Git commands through Guardian so ordinary Git workflows can be reviewed separately from direct metadata writes." },
]

There is no ~/.codex/rules/default.rules entry for git.

The fixture is a normal Git repository created outside /tmp. The task prompt asks Codex to create a file, run git add, and run git commit.

Steps

From managed_codex_config:

sudo mkdir -p /etc/codex
sudo cp repros/git-prefix-prompt-deny-read/requirements.toml /etc/codex/requirements.toml

bash repros/git-prefix-prompt-deny-read/scripts/create-fixture.sh --reset
bash repros/git-prefix-prompt-deny-read/scripts/launch-codex.sh

For an automated headless check:

bash repros/git-prefix-prompt-deny-read/scripts/test-repro.sh

What is the expected behavior?

Codex should preserve the normal workspace Git permission path for ordinary user-requested Git operations in the active repository.

For the prompt:

create codex-repro-added.txt,
run git add codex-repro-added.txt,
run git commit -m "test: reproduce managed git prompt permission issue",
Codex should either:

allow the normal Git metadata writes for the active worktree after Guardian approval, or
provide a supported way for managed requirements to express that ordinary current-worktree Git commands are allowed while direct Git metadata probes, hook edits, config edits, ref tampering, and permission repairs remain reviewable or denied.

Additional information

Discovered Details

• When no managed Git rule is present, ordinary Git porcelain can be treated differently from direct metadata writes.
• Adding permissions.filesystem.deny_read appears to move execution onto a permission evaluation path where Git metadata writes are sandbox-blocked.
• Managed rules.prefix_rules supports decision = "prompt" and decision = "forbidden" for this use case; decision = "allow" is not available as an escape hatch for known-safe command prefixes.
• Setting git to decision = "prompt" does route the command into review, but it does not restore the desired permission evaluation path for normal active-worktree Git metadata writes after approval/retry.
• This leaves managed policy authors unable to express the intended split:
• allow ordinary user-requested Git operations in the current active worktree,
• review or deny direct .git metadata writes, hooks, config, ref tampering, index mutation probes, and permission repairs.

Impact

Managed Codex deployments that need even a small filesystem deny list may accidentally block normal Git development workflows. The available prefix-rule decisions do not appear to let administrators recover normal Git porcelain behavior without also losing the ability to review or deny risky Git-adjacent operations.

Request

Please clarify or change the managed permission model so that administrators can safely support ordinary Git workflows under managed filesystem restrictions.

Potential fixes:

• Preserve normal active-worktree Git metadata writes even when unrelated permissions.filesystem.deny_read entries are present.
• Add a first-class policy concept for ordinary current-worktree Git porcelain operations.
• Add a supported allow decision or narrower rule type that can allow normal Git commands without allowing direct Git metadata writes.

Ensure decision = "prompt" approval can retry using the same permission path that would allow normal current-worktree Git metadata writes.

git-prefix-prompt-deny-read.zip