Windows elevated sandbox requires repeated approval for git worktree operations because .git is denied

Summary

In codex-cli 0.123.0 on Windows, git worktree operations now require repeated manual approval when running with workspace-write and windows.sandbox = "elevated".

The workspace itself is trusted and writable, but writes under .git are denied by the Windows sandbox. As a result, normal Git workflows such as creating an issue worktree, committing, merging, or cleaning up worktrees frequently leave the sandbox and require approval.

Environment

• Codex CLI: codex-cli 0.123.0
• OS: Windows 10 Pro, WindowsVersion 2009
• Sandbox mode: workspace-write
• Windows sandbox backend: elevated
• GitHub CLI used for this report: gh 2.91.0
• Project is trusted in Codex config
• The repository/worktree path is inside configured writable roots

What changed

This appears to be caused by the elevated Windows sandbox now inheriting the legacy deny-write paths for protected directories such as .git.

Relevant upstream change:

• #17365: Include legacy deny paths in elevated Windows sandbox setup

Before this change, versions such as rust-v0.112.0 through rust-v0.114.0 appear to contain the earlier .git protection logic, but not the elevated-backend merge introduced by #17365. In practice, the elevated backend did not prompt for these .git writes as frequently in that older setup.

Steps to reproduce

1. On Windows, configure Codex with:

sandbox_mode = "workspace-write"

[windows]
sandbox = "elevated"

1. Trust a project whose repository path is inside a writable root.
2. Start Codex in that repository.
3. Ask Codex to create an issue worktree, for example:

git worktree add .worktrees/S1-04 -b S1-04 sprint01

1. Observe that the operation requires approval because Git needs to write under .git.
2. Continue normal issue-branch workflow, such as commit, merge, prune, or remove worktree.
3. Observe repeated approvals for normal Git metadata writes.

Expected behavior

Trusted workspaces should allow common Git metadata operations needed for normal development workflows without repeated approval, especially when the operation is initiated inside the trusted repository and the target worktree is under the repository, for example .worktrees/<issue-id>.

At minimum, there should be a documented and configurable way to allow common Git metadata writes for trusted repositories while keeping the default protection for untrusted workspaces.

Actual behavior

Even though the repository path is trusted and inside writable roots, the sandbox treats .git as protected/denied. Commands that update repository metadata need to leave the sandbox and prompt for approval repeatedly.

This makes worktree-based workflows noisy and difficult to automate. A typical issue workflow may require approval for:

• git worktree add
• git add / git commit
• git merge
• git worktree remove
• git worktree prune

Why this matters

Worktree-based development is a common way to isolate issue branches, sprint branches, and parallel agent work. Requiring approval every time Git updates .git makes the workflow much less usable in trusted local projects.

I understand why .git is protected by default: it prevents unintended repository metadata writes. The problem is that there is currently no practical escape hatch for trusted repositories where Git operations are an intentional part of the workflow.

Possible fixes

Some possible approaches:

1. Add a config option to allow Git metadata writes for trusted repositories, for example allow_git_metadata_writes = true under the workspace sandbox config.
2. Allow a narrower set of Git operations under .git when the command is git and the working directory is inside a trusted workspace.
3. Treat .git/worktrees, refs, index locks, and other Git-managed metadata differently from arbitrary writes under .git.
4. Document the recommended configuration for worktree-heavy workflows if the current behavior is intentional.

Related issues / PRs

• #7071: CLI sandbox cannot commit because .git is read-only
• #15505: .git is mounted read-only even though Codex is configured for workspace-write
• #17036: allow limited git writes in workspace sandbox
• #17365: Include legacy deny paths in elevated Windows sandbox setup