Codex Desktop’s Windows `workspace-write` sandbox creates an empty `<workspace>\.git` directory in a workspace that is not a Git repository

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

Version 26.707.30751

What subscription do you have?

Enterprise

What platform is your computer?

Windows 11

What issue are you seeing?

The sandbox appears to materialize the missing path so it can apply a deny
ACL. Because .git is a repository-discovery sentinel, its mere existence
changes the behavior of Visual Studio and other developer tools.

In this case, Visual Studio detects malformed Git metadata above a large,
explicitly TFVC-bound solution and fails to load the solution.

Environment

• Codex Desktop: 26.707.3351.0
• Platform: Microsoft Windows NT 10.0.26200.8655 x64
• Sandbox mode: workspace-write
• Windows sandbox configuration: [windows] sandbox = "elevated"
• Visual Studio: 18 Professional
• Source control: TFVC, not Git
• Solution: 88 TFVC-bound projects

Correlated evidence

An apply_patch began at approximately:

2026-07-10T16:02:42.867Z

The sandbox log then recorded:

[2026-07-10 10:02:43.265 codex.exe] setup refresh: spawning
codex-windows-sandbox-setup.exe
(cwd=<workspace>)

[2026-07-10T16:02:43.434435600+00:00]
applied deny ACE to protect <workspace>\.git

The resulting .git directory contained no HEAD, config, refs, objects,
or other metadata. Git itself reported that the directory was not a Git
repository.

The same sandbox behavior was independently observed in another workspace
and in Codex-generated visualization roots. The directories’ creation
timestamps exactly matched the ACL operations in the sandbox log.

The solution contains:

GlobalSection(TeamFoundationVersionControl) = preSolution
SccNumberOfProjects = 88

There is no git init, clone, worktree, or project script creating .git.

Impact

• Silently mutates the user’s source workspace.
• Imposes Git repository semantics on non-Git workspaces.
• Breaks Visual Studio/TFVC solution loading.
• Reappears after manual cleanup.
• Makes Codex write mode unusable with this workspace.

Expected behavior

Codex must never create a reserved source-control discovery sentinel merely
to protect it.

If .git exists, protecting it is reasonable. If it does not exist, the
sandbox must skip that path or use a mechanism that does not materialize it.

The behavior must also be tested with non-Git workspaces, including TFVC,
Perforce, Subversion, Mercurial, and workspaces with no source control.

What steps can reproduce the bug?

Steps to reproduce

1. Start with a known non-Git workspace and verify that <workspace>\.git

does not exist.

1. Open that workspace in Codex Desktop using workspace-write.
2. Trigger an edit that uses apply_patch.
3. Observe Windows sandbox setup/refresh.
4. Observe that <workspace>\.git now exists and is completely empty.
5. Open a Visual Studio solution beneath that workspace that is explicitly

bound to TFVC.

1. Visual Studio detects the ancestor .git marker and solution loading fails.
2. Delete the empty .git, restart Visual Studio, and solution loading works.
3. A later Codex sandbox refresh recreates .git.

What is the expected behavior?

I expect it not to be so dumb as to randomly add source control files/folders that I clearly don't use. I expect the developers to be know that Git is NOT the only source control system in the world.

Additional information

_No response_