Non-pinned Codex threads disappear after startup when thread `cwd` uses the `\\?\` path prefix
What version of the Codex App are you using (From “About Codex” dialog)?
26.601.21317
What subscription do you have?
Pro $200
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
## Title
Windows: non-pinned Codex threads disappear after startup when thread `cwd` uses the `\\?\` path prefix
## Summary
In Codex Desktop on Windows, project threads briefly appear when opening the app, then disappear after a few milliseconds. After the refresh/hydration step, only pinned threads remain visible.
The threads are not deleted or archived. They still exist in local state and can be retrieved through internal thread listing. This appears related to inconsistent Windows path normalization between the active workspace root and the stored thread `cwd`.
## Environment
- App: Codex Desktop
- Version observed: `26.601.2237.0`
- OS: Windows
- Workspace type: local project
- Project path redacted as: `<workspace-root>`
## Actual Behavior
1. Open Codex Desktop.
2. Project threads appear briefly.
3. After a short refresh/hydration, all non-pinned threads disappear.
4. Only pinned threads remain visible in the sidebar.
## Expected Behavior
All non-archived project threads should remain visible in the project sidebar, regardless of whether they are pinned.
## Diagnostics
Local state shows that the threads still exist and are not archived.
Observed counts:
- Non-archived threads: `210`
- Archived threads: `68`
- Pinned thread IDs: `6`
- Non-archived, non-pinned threads exist but are hidden from the UI.
The suspicious mismatch is:
```text
Active workspace root:
<workspace-root>
Thread cwd stored in SQLite:
\\?\<workspace-root>
Affected records have:
archived = 0
cwd = \\?\<workspace-root>
missing thread-workspace-root-hint entry
Pinned threads remain visible, likely because the pinned section is global and does not depend on matching the active workspace root.
Hypothesis
The sidebar/project thread filter may be comparing workspace paths literally without normalizing Windows extended-length paths.
This comparison fails:
<workspace-root> !== \\?\<workspace-root>
As a result, non-pinned project threads are filtered out after the initial render. Pinned threads remain visible because they bypass or use a different display path.
Impact
Most project history becomes inaccessible from the sidebar even though the data still exists locally. This can easily look like data loss.
Suggested Fix
Normalize Windows paths before comparing workspace roots and thread cwd, especially stripping or canonicalizing the \\?\ extended-length prefix.
Potentially affected fields:
- active workspace roots
- saved workspace roots
- thread
cwd - thread workspace root hints
- sidebar/project grouping filters
### What steps can reproduce the bug?
1. Open Codex Desktop on Windows.
2. Select a local project workspace that has existing non-pinned threads.
3. Wait for the sidebar to finish loading/hydrating.
4. Observe that project threads briefly appear, then disappear after a few milliseconds.
5. Check the sidebar again: only pinned threads remain visible, while non-pinned threads are hidden.
### What is the expected behavior?
_No response_
### Additional information
_No response_This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗