Codex Desktop should diagnose Git safe.directory / ownership failures when WorkTree project association fails #24484

What version of the Codex App are you using?

Codex Desktop on Windows. I can provide the exact version later if needed, but this report is mainly about a diagnostic gap around Git metadata / project association.

What platform is your computer?

Windows.

Summary

This is a follow-up / diagnostic report related to disappearing Codex Desktop WorkTree threads.

In my case, the Codex-managed Git worktree itself was created correctly, but the new WorkTree thread briefly appeared under the original project in the sidebar and then disappeared after the sidebar refreshed. The thread still existed locally, so this was not data loss. The root cause in my setup was a local Git ownership / safe.directory mismatch that prevented Codex/Git from reading the repository origin from the repo's .git directory.

I am filing this separately from the general disappearing-thread reports because the useful finding is not just "WorkTree disappears", but a concrete diagnostic path and possible product improvement:

Codex Desktop should surface a clear diagnostic when WorkTree project association fails because Git cannot read repository metadata from .git due to ownership / safe.directory.

Related issue: #14519.

What happened, step by step

1. I opened a normal Git project in Codex Desktop on Windows.

2. I started a new Codex Desktop WorkTree thread from that project.

3. Codex created the physical managed worktree under:

   CODEX_HOME\worktrees\<id>\<repo-name>
   

4. The worktree was valid according to Git:

   git worktree list --porcelain

5. The WorkTree was detached HEAD, which appears to be normal for Codex-managed WorkTrees.

6. The new thread existed in local Codex state / rollout files.

7. The new thread appeared in the original project sidebar briefly.

8. After the sidebar refreshed, the thread disappeared from the original project grouping.

9. To access it, I had to manually open the CODEX_HOME\worktrees\... folder as if it were a separate project.

So the physical Git layer was fine, but the Desktop project/thread association layer was not persisted correctly.

What I checked first

These were not the bug in my case:

• The worktree being located under CODEX_HOME\worktrees.
• Detached HEAD.
• Git worktree registration.
• Missing physical worktree folder.
• Data loss.

The suspicious part was the missing association between the new WorkTree thread and the original project root.

How I tried to solve it before finding the root cause

The confusing part was that the WorkTree was not obviously "failed". It was created, it existed on disk, and Git knew about it. Because of that, I initially suspected the wrong things.

The rough path was:

1. I first thought the problem might be that Codex was placing WorkTrees under CODEX_HOME\worktrees instead of next to my project.
2. After checking the Codex WorkTrees behavior, I realized that this location is normal for Codex-managed WorkTrees.
3. I then suspected stale Codex Desktop state, because old hidden WorkTree threads existed locally and some sidebar/project metadata looked out of sync.
4. Manually aligning local metadata such as workspace-root hints could make some already-created hidden threads visible again, but that only recovered old threads. It did not fix newly created WorkTrees.
5. I tested fresh WorkTree creation again. The new WorkTree still appeared briefly under the original project and then disappeared from the sidebar.
6. That made the problem narrower: Git worktree creation was healthy, but Codex Desktop was not persisting the new thread's association with the original project root.
7. The key clue came from the Desktop logs: No matching origin found originUrl=<repo origin url>.
8. I then compared Git origin lookup from the repo root versus from the .git directory.

That last check is what exposed the actual local cause in my setup.

Important log clue

The useful log clue was:

No matching origin found originUrl=<repo origin url>

That suggested Codex Desktop could not match the WorkTree thread back to the original project by Git origin/root metadata.

Diagnostic commands

This command worked:

git -C "<MAIN_WORKSPACE_ROOT>" config --get remote.origin.url

But this command failed or returned nothing:

git -C "<MAIN_WORKSPACE_ROOT>\.git" config --get remote.origin.url

That difference was the key.

Root cause in my setup

The repository root was owned by my normal Windows user, but the .git directory itself had a different local owner from an older setup / folder move.

My global Git safe.directory config trusted the repository root, but it did not trust the .git directory path.

Because Codex Desktop / its Git worker appeared to query Git metadata from inside .git, Git refused to read the repo metadata from that location. As a result, Codex Desktop could not match the origin/project root and did not persist the WorkTree thread association for the sidebar.

Minimal workaround that fixed new WorkTree grouping for me

First, verify whether Git can read the origin from .git:

git -C "<MAIN_WORKSPACE_ROOT>\.git" config --get remote.origin.url

If that fails or prints nothing, add a narrow trust entry for that repo's .git directory:

git config --global --add safe.directory "<MAIN_WORKSPACE_ROOT>/.git"

Then verify again:

git -C "<MAIN_WORKSPACE_ROOT>\.git" config --get remote.origin.url

After restarting Codex Desktop, newly created WorkTree threads stayed associated with the original project again in my setup.

Prevention I used afterwards

For future projects under my normal project folder, I used scoped wildcard entries instead of trusting every repository globally:

git config --global --add safe.directory "C:/Users/<you>/Projects/*"
git config --global --add safe.directory "C:/Users/<you>/.codex/worktrees/*"

I would not recommend this as a universal fix for everyone, and I would not recommend safe.directory=* as a convenience workaround, because that disables Git's ownership protection too broadly.

The cleaner long-term fix is probably to repair the Windows owner / ACL of the repository's .git directory or reclone the repository cleanly.

Expected Codex Desktop behavior

Codex Desktop probably should not automatically change safe.directory, because that is a Git security setting.

But Codex Desktop could detect this situation and show a clear diagnostic before or during WorkTree creation:

Codex created the Git worktree, but could not associate it with the original project because Git could not read repository metadata from .git. Check repository ownership or safe.directory.

At minimum, it would help if the UI surfaced that origin/project-root matching failed, instead of allowing the WorkTree thread to appear briefly and then silently disappear from the original project sidebar.

Why this matters

For users who are newer to Git worktrees, Windows ownership, or Git's safe.directory checks, the current symptom is very confusing:

• the worktree exists;
• the thread exists;
• Git worktree creation succeeded;
• but the Codex Desktop sidebar loses the project association.

That makes the issue look like a Codex data-loss or UI bug, when in this specific case the actionable cause was a Git trust / metadata lookup failure.