Windows sandbox helper creates an empty .git directory for a nonexistent deny-write path, triggering repeated Git probes and high Defender CPU usage

What version of the Codex App are you using (From “About Codex” dialog)?

26.623.19656.0

What subscription do you have?

Plus

What platform is your computer?

Windows11

What issue are you seeing?

The Codex Windows sandbox filesystem helper creates an empty .git directory in a workspace that is intentionally not a Git repository.

This happens after Codex uses file modification tools such as apply_patch.

I captured the directory creation with Microsoft Process Monitor. The process that creates the directory is codex.exe, running as the Windows restricted-token filesystem helper.

Observed process command line:

codex.exe --run-as-windows-sandbox
--windows-sandbox-level restricted-token
--workspace-root E:\Agent\Project\General
--deny-write-paths-json ["E:\Agent\Project\General\.git"]
...
codex.exe --codex-run-as-fs-helper

The exact directory creation event was:

Time: 10:51:21.3906739
Process: codex.exe
PID: 19512
Operation: CreateFile
Path: E:\Agent\Project\General\.git
Result: SUCCESS
Disposition: Create
Options: Directory
OpenResult: Created

The same process immediately performed:

QueryDirectory
QuerySecurityFile
SetSecurityFile

This indicates that the restricted-token filesystem helper receives .git as a deny-write path and creates the directory in order to apply a DACL, even though the path did not exist before.

The created .git directory is empty and is not a valid Git repository.

After the empty .git directory appears, the Codex Desktop Git worker repeatedly treats the workspace as a possible Git repository and starts many short-lived git.exe processes.

Observed repeated commands include:

git.exe -c core.hooksPath=NUL -c core.fsmonitor=false rev-parse --git-dir
git.exe -c core.hooksPath=NUL -c core.fsmonitor=false rev-parse HEAD
git.exe -c core.hooksPath=NUL -c core.fsmonitor=false remote -v
git.exe -c core.hooksPath=NUL -c core.fsmonitor=false status --porcelain
git.exe config --null --get core.fsmonitor

This causes a process creation loop. Microsoft Defender then scans the repeatedly created Git processes and related file activity, resulting in:

High Antimalware Service Executable CPU usage
Increased disk activity
High fan speed
Many simultaneous or rapidly created git.exe processes

Renaming or deleting the empty .git directory immediately stops the repeated Git probing. However, Codex recreates it again after another file-editing task.

The workspace was moved outside OneDrive and the problem still reproduces, so OneDrive is not the root cause.

Pure shell tasks do not reproduce the issue. File modifications using apply_patch or similar Codex file-editing tools reproduce it consistently.

Expected behavior:

A nonexistent path listed in --deny-write-paths-json should not be created merely to apply a deny ACL.

The sandbox helper should behave approximately like this:

if deny_path.exists() {
apply_deny_acl(deny_path)?;
} else {
// Do not materialize a nonexistent protected path.
continue;
}

For a Local workspace that is not a Git repository, Codex should not create .git, and the Git worker should not continuously probe an empty or invalid Git directory.

What steps can reproduce the bug?

On Windows, create a normal directory that is not a Git repository.

Example:

New-Item -ItemType Directory "E:\CodexNoGitTest" -Force
Set-Content "E:\CodexNoGitTest\test.txt" "hello"

Confirm that the workspace does not contain .git:

Test-Path "E:\CodexNoGitTest\.git"

Expected result:

False
Open this directory in the Codex Windows App using Local mode with the Windows sandbox enabled.

Ask Codex to make a simple file edit that uses its file modification or patch tool.

Example request:

Change the contents of test.txt from "hello" to "hello world".

After the task finishes, inspect the workspace root:

Get-ChildItem "E:\CodexNoGitTest" -Force

Observe that Codex has created:

E:\CodexNoGitTest\.git

Inspect the directory:

Get-ChildItem "E:\CodexNoGitTest\.git" -Force

It is empty and is not a valid Git repository.

Monitor running Git processes:

Get-CimInstance Win32_Process |
Where-Object { $_.Name -eq "git.exe" } |
Select-Object ProcessId, ParentProcessId, CommandLine

Observe repeated Git repository probes such as:

rev-parse --git-dir
rev-parse HEAD
remote -v
status --porcelain
config --get core.fsmonitor
Rename or remove only the empty .git directory:
Rename-Item "E:\CodexNoGitTest\.git" ".git.disabled-empty"
Observe that the repeated Git probes stop.
Run another Codex file-editing task and observe that the empty .git directory is created again.

Additional Process Monitor reproduction:

Filter by:

Path is E:\CodexNoGitTest\.git
Operation is CreateFile
The first successful creation event is performed by codex.exe.

The process is running with:

--run-as-windows-sandbox
--windows-sandbox-level restricted-token
--deny-write-paths-json ["E:\CodexNoGitTest\.git"]
--codex-run-as-fs-helper

The CreateFile event uses:

Disposition: Create
Options: Directory
OpenResult: Created

This suggests the bug is in the shared Windows restricted-token filesystem helper rather than in Git, Defender, OneDrive, the shell, or a workspace script.

What is the expected behavior?

_No response_

Additional information

_No response_