Desktop-created worktree thread exists locally but never appears in Codex Desktop thread list

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #14370
• #13713
• #13846
• #14182

Powered by Codex Action

looks like this is part of #10347

Got the same issue.

I saw a related Windows + WSL worktree failure.

What I observed:
• Codex created linked worktrees under C:\Users\mike\.codex\worktrees\...
• the app/workflow did not behave as expected afterward
• the extra linked worktrees persisted and surfaced in VSCode source control
• they had to be removed manually with git worktree remove --force ... and git worktree prune

Environment:
• Windows 11
• WSL Ubuntu
• repo opened from WSL path

Session ID from in-app feedback:
13cb61d3-2d73-46b4-9120-19248ea0665d

Adding this as another data point in case it is the same desktop worktree-association bug family.

I have one additional data point that may narrow this down.

I compared two Windows machines:

• Affected machine: CODEX_HOME is customized to D:\Tools\Codex\Home
• Unaffected machine: CODEX_HOME is the default %USERPROFILE%\.codex

On the affected machine, Fork into new worktree created the child threads and worktree directories successfully, but the new threads did not appear in the Codex Desktop UI under the original project.

On the unaffected machine, the same operation worked as expected: the new worktree thread appeared in the UI.

The key difference I found is in .codex-global-state.json.

On the unaffected machine, the visible worktree-forked thread was automatically added to thread-workspace-root-hints.

The mapping had this shape:

<child-thread-id> -> <original-project-root>

The child thread’s actual cwd was still the worktree path under the Codex home worktrees directory, but thread-workspace-root-hints mapped the child thread back to the original project root. That seems to be what lets Desktop show the worktree thread in the original project’s thread list.

On the affected machine, the missing worktree-forked threads existed locally with:

• archived = 0
• cwd = D:\Tools\Codex\Home\worktrees\<worktree-id>\<repo-name>
• rollout/session JSONL files present
• worktree directories present at creation time

But there was no corresponding thread-workspace-root-hints entry for those child thread IDs, so the UI could not associate them with the original project.

A temporary local recovery was possible by fully exiting Codex Desktop, adding the missing mappings to thread-workspace-root-hints in .codex-global-state.json, and restarting Codex Desktop.

This makes me suspect the bug may be specifically in the workspace-root hint registration path for worktree forks when CODEX_HOME is set to a non-default Windows path, rather than in git worktree creation itself.

Version details from the affected environment:

• Windows
• Codex Desktop: 26.513.x
• CLI in session metadata: 0.131.0-alpha.9
• Custom CODEX_HOME: D:\Tools\Codex\Home

Correction / retraction: my previous comment was premature.

The workaround I described did restore visibility for already-created worktree threads in my local Codex Desktop sidebar, but it did not fix the underlying bug.

After restoring those existing chats, creating a new thread from the same project can still start it under %USERPROFILE%\.codex\worktrees\<id>\<repo-name> and it can still fail to be associated with the original project as expected.

So the confirmed narrower finding is only this:

• affected threads were not data-loss cases;
• existing hidden threads could be made visible again by aligning local metadata such as .codex-global-state.json hints and state_5.sqlite -> threads.cwd;
• however, Codex Desktop can still create new worktree-backed threads that are not project-associated correctly.

Please do not treat the earlier workaround as a full bug fix. At most it is a local recovery method for already-created hidden threads, and the root Desktop workspace/thread association issue remains.

I have a more controlled follow-up data point.

This time I tested with a fresh Codex home on the affected Windows machine, not the previously migrated/old state.

Environment:

• Windows
• Codex Desktop package observed locally: 26.519.5221.0
• User-level CODEX_HOME points to a non-default Windows path: D:\Tools\Codex\Home
• The previous active home was renamed away, and a fresh home was used for this test. After the test I renamed that fresh home to D:\Tools\Codex\Home.testing3 for inspection.

Test setup:

1. Fully closed Codex and Chrome.
2. Used a fresh D:\Tools\Codex\Home as the active Codex home.
3. Signed in again.
4. Created a clean test repository from normal PowerShell, not from inside Codex:

• D:\Projects\Sandbox\Test4
• git init
• added README.md
• committed successfully
• renamed branch to main
• made a second commit

1. Added D:\Projects\Sandbox\Test4 as a Codex Desktop project.
2. Started a normal chat in that project.
3. Used the sidebar context menu: Fork into new worktree.

Observed behavior:

• Worktree creation succeeded.
• The setup log showed:
• Preparing worktree (detached HEAD 6581ec5)
• HEAD is now at 6581ec5 2nd commit
• Worktree created at D:\Tools\Codex\Home\worktrees\6448\Test4
• No local environment selected
• The forked conversation appeared briefly in the project sidebar, then disappeared from the project list.
• The forked conversation was not a data-loss case. It existed locally on disk and in the state DB.

Inspection after the test:

state_5.sqlite -> threads contained the original thread:

{
  "id": "019e59d9-a704-7bb3-ae1a-f2b1eaf1a8f7",
  "title": "こんにちは",
  "cwd": "\\\\?\\D:\\Projects\\Sandbox\\Test4",
  "archived": 0,
  "git_branch": "main",
  "git_sha": "6581ec53b5e859a401b78681a653b1c6949b5b96"
}

and the forked worktree thread:

{
  "id": "019e59da-2d52-7cf1-abd9-18fc2efff5e6",
  "title": "こんにちは",
  "cwd": "\\\\?\\D:\\Tools\\Codex\\Home\\worktrees\\6448\\Test4",
  "archived": 0,
  "git_branch": null,
  "git_sha": null
}

The forked rollout file also existed:

D:\Tools\Codex\Home.testing3\sessions\2026\05\24\rollout-2026-05-24T20-58-56-019e59da-2d52-7cf1-abd9-18fc2efff5e6.jsonl

session_index.jsonl contained only the original thread, not the forked worktree thread:

{"id":"019e59d9-a704-7bb3-ae1a-f2b1eaf1a8f7","thread_name":"こんにちは","updated_at":"2026-05-24T11:58:31.8079686Z"}

.codex-global-state.json had the expected project root entries:

electron-saved-workspace-roots: D:\Projects\Sandbox\Test4
project-order: D:\Projects\Sandbox\Test4
active-workspace-roots: D:\Projects\Sandbox\Test4

but it had no thread-workspace-root-hints key at all.

The worktree itself existed and was a detached HEAD at the expected commit:

D:\Tools\Codex\Home.testing3\worktrees\6448\Test4
## HEAD (no branch)
HEAD = 6581ec53b5e859a401b78681a653b1c6949b5b96

So this looks narrower than my earlier report: with a fresh non-default Windows CODEX_HOME on D:, worktree creation can succeed, but Codex Desktop does not persist enough project/sidebar association metadata for the forked worktree thread. The thread exists and is unarchived, but it drops out of the project sidebar after the initial live display.

I found one concrete local cause/workaround for this class of disappearing Codex Desktop WorkTree threads on Windows.

Full A-to-Z write-up: #24484.

This does not mean every disappearing WorkTree thread has this exact cause. In my case, the Git worktree was created correctly, but Codex Desktop failed to keep the new WorkTree thread associated with the original project in the sidebar.

TL;DR workaround that fixed it for me

Check whether Git can read the repo origin from the repository's .git directory:

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

If that fails or prints nothing, but this works:

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

then add a narrow trust entry:

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

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.

Symptom I saw

• A new WorkTree thread was created from an existing Windows project.
• The physical worktree existed under CODEX_HOME\worktrees\<id>\<repo-name>.
• git worktree list --porcelain showed the worktree correctly.
• The WorkTree thread appeared briefly under the original project in the sidebar.
• After the sidebar refreshed, it disappeared from the original project grouping.
• To access it, I had to manually open the CODEX_HOME\worktrees\... folder as if it were a separate project.

So this was not data loss and not a failed Git worktree creation. It looked like a Desktop project/sidebar association failure.

What was normal / not the bug

These were expected or healthy in my case:

• WorkTree path under CODEX_HOME\worktrees.
• Detached HEAD.
• Valid Git worktree registration.
• Existing local thread / rollout data.

How I narrowed it down

1. I first suspected the CODEX_HOME\worktrees location, but that appears normal for Codex-managed WorkTrees.
2. I then suspected stale Codex Desktop state. Manually recovering old hidden threads through local metadata could make some existing threads visible again, but it did not fix newly created WorkTrees.
3. A fresh WorkTree still appeared briefly and then disappeared after sidebar refresh.
4. That narrowed the issue down to Desktop not persisting the association between the new WorkTree thread and the original project root.
5. The useful log clue was:

``text
No matching origin found originUrl=<repo origin url>
``

1. That led me to compare Git origin lookup from the repo root versus from .git.

Root cause in my setup

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

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

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

Prevention I used afterwards

For future projects under my normal project folder, I added scoped wildcard entries instead of trusting everything 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 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.

Product suggestion

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

But it would be helpful if Desktop surfaced a clear diagnostic when project/worktree association fails because Git cannot read repository metadata from .git, instead of letting the WorkTree thread briefly appear and then silently disappear from the original project sidebar.