Windows: .git owned by CodexSandboxOffline causes Codex project detection and Git clients to reject repository

Open 💬 2 comments Opened Aug 11, 2026 by vygkaz

Codex App version

Codex Desktop 26.803.5235.0.

Platform

Windows: Microsoft Windows NT 10.0.26200.0
Git: git version 2.54.0.windows.1

Summary

On Windows, a repository initialized from a Codex task had its .git directory owned by the Codex sandbox account while the project directory remained owned by the interactive Windows user.

Git's ownership protection then rejected the repository when Codex Desktop and external Git clients accessed it as the interactive user. Codex Desktop silently failed to recognize the project as a Git repository, while SourceTree displayed Git's detected dubious ownership error.

Repository state before remediation

Windows ownership was:

<project-root>       DEV\vygka
<project-root>\.git  DEV\CodexSandboxOffline

The repository itself was valid and contained a branch and commit. However, Git commands executed as DEV\vygka failed with code 128:

fatal: detected dubious ownership in repository at '<project-root>'
'<project-root>/.git' is owned by:
    DEV/CodexSandboxOffline
but the current user is:
    DEV/vygka

Observed application behavior:

SourceTree could not open the repository because git log exited with code 128.
Codex Desktop did not show the project as a Git repository.
The project was absent from Codex's local Git-project inventory.

Steps to reproduce

Create or open a Windows project directory owned by the interactive user.
From a Codex task running as DEV\CodexSandboxOffline, initialize Git and create a commit.
Inspect the owner of the project directory and its .git directory:

``powershell (Get-Acl "<project-root>").Owner (Get-Acl "<project-root>\.git").Owner``

Open the repository in a Git client running as the interactive user.
Refresh or reopen the project in Codex Desktop.

Actual behavior

The project directory and .git directory have different owners. Git rejects the repository for the interactive user. SourceTree reports the ownership error, and Codex Desktop treats the project as if no Git repository were available.

Verified remediation

The .git owner was changed from an elevated PowerShell shell:

icacls "<project-root>\.git" /setowner "DEV\vygka" /T /C

No Git safe.directory exception was added.

After the ownership change:

<project-root>       DEV\vygka
<project-root>\.git  DEV\vygka

Both affected applications recovered immediately:

SourceTree opened the repository successfully.
Codex Desktop recognized the project as a Git repository.
Codex's project inventory reported the project with isGitRepository: true.

This before/after result isolates the ownership mismatch as the cause.

Expected behavior

Git repositories initialized or modified by a Codex task inside a user-owned project should remain usable by the interactive Windows user.

Codex should either:

preserve or restore appropriate ownership when creating the .git directory; or
detect Git's dubious-ownership failure and display an actionable diagnostic instead of silently classifying the project as non-Git.

Codex should not broadly bypass Git's ownership protection or automatically add unrestricted safe.directory entries.

View original on GitHub ↗

2 Comments

blackcat-team · 4 days ago

I can confirm the same .git ownership problem on a newer Codex Desktop package.

During investigation of a Windows sandbox failure, Codex Desktop started reporting:

fatal: detected dubious ownership in repository at
'E:/PythonProject/Scripts/delphi-agent-arena'

'E:/PythonProject/Scripts/delphi-agent-arena/.git' is owned by:
    LenovoNote/CodexSandboxOffline

but the current user is:
    LENOVONOTE/redli

The package path observed in the same Codex logs was:

OpenAI.Codex_26.818.5229.0_x64__2p2nqsd0c76g0

Get-Acl confirmed that .git was actually owned by the sandbox account, not just misreported by Git.

I repaired only the .git ownership from an elevated PowerShell session:

icacls "E:\PythonProject\Scripts\delphi-agent-arena\.git" /setowner "LENOVONOTE\redli" /T /C

I did NOT add a safe.directory exception.

After remediation:

Owner: LENOVONOTE\redli
AreAccessRulesProtected: False

and:

git -C E:\PythonProject\Scripts\delphi-agent-arena status --short --branch

worked normally again without dubious ownership.

This happened as part of a broader elevated Windows sandbox ACL failure where the setup helper was repeatedly returning:

SetNamedSecurityInfoW failed: 5

while applying ACLs.

So I can confirm that the sandbox can still leave .git owned by CodexSandboxOffline, and restoring ownership to the interactive user is sufficient to recover normal Git behavior without weakening Git's ownership protection via safe.directory.

XiaobiChanging · 2 days ago

I reproduced this with a Codex-created linked worktree, which appears to extend the issue beyond repositories created with \git init\.

Environment

Windows 11 x64
Codex Desktop: \26.818.3698.0\
Git for Windows: \2.51.2.windows.1\
Sandbox mode: \workspace-write\
Windows sandbox: \elevated\

Observed ownership

A linked worktree was created during a Codex multi-agent workflow. Before remediation, ownership was:

\\\text <WORKTREE_ROOT> <MACHINE>\CodexSandboxOffline <WORKTREE_ROOT>\.git <MACHINE>\CodexSandboxOffline <MAIN_REPO>\.git\worktrees\<WORKTREE> <MACHINE>\<USER> \\\

The worktree \.git\ entry was the normal linked-worktree pointer file:

\\\text gitdir: <MAIN_REPO>/.git/worktrees/<WORKTREE> \\\

Running Git from an ordinary PowerShell session as the interactive user failed:

\\\text fatal: detected dubious ownership in repository at '<WORKTREE_ROOT>' '<WORKTREE_ROOT>/.git' is owned by: <MACHINE>/CodexSandboxOffline but the current user is: <MACHINE>/<USER> \\\

Both \git status --short --branch\ and \git log --oneline master..HEAD\ were rejected.

A sample ownership scan also showed a mixture of files and directories owned by the interactive user and \CodexSandboxOffline\ inside the worktree.

Remediation and verification

I did not add a \safe.directory\ exception.

From an elevated PowerShell session, I restored ownership of this specific worktree recursively to the interactive user:

\\\powershell takeown /F "<WORKTREE_ROOT>" /R /D Y icacls "<WORKTREE_ROOT>" /setowner "<MACHINE>\<USER>" /T /C \\\

Afterward:

\\\text <WORKTREE_ROOT> <MACHINE>\<USER> <WORKTREE_ROOT>\.git <MACHINE>\<USER> \\\

The same ordinary PowerShell Git commands succeeded immediately, and the linked worktree and its commits were intact.

This suggests the ownership problem also affects Codex-created linked worktrees. It is especially disruptive for worktree-based agent workflows because the worktree may function inside the sandbox but is rejected by Git when the interactive user later tries to inspect or push it.