Repository navigation
Non-pinned Codex threads disappear after startup when thread cwd uses the \\?\ path prefix #26411
Description
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_
Activity
github-actions commentedon Jun 4, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
DoomDeity commentedon Aug 5, 2026
Follow-up from a Windows Codex Desktop reproduction (2026-08-06). This appears to be a related but distinct failure mode: archiving one legacy local thread caused unrelated unarchived threads to disappear from the normal sidebar/list projection.
Environment:
0.147.0-alpha.1.2legacyObserved sequence:
019fd146-08ff-7e02-b519-6cca13e625b9019fd2a0-05d9-7f90-906c-a8851353d1672026-08-05T18:55:06Z:set_thread_archived(threadId=019fd146-08ff-7e02-b519-6cca13e625b9, archived=true)019fcd5b-fe2f-7a00-9a47-4e3f8f8f06f7019fcd85-9be1-7661-923d-ee43b19961e3019fd0ab-0c4e-7041-a44d-747f0877962aarchived=0andis_pinned=0; their local rollout data was still present. Pin/unpin operations changed their visibility, and a later refresh restored the normal sidebar view.Expected:
The local screenshot and raw session JSONL are preserved privately; I am not attaching them because they may contain proprietary project content and local paths. The distinguishing evidence is the successful archive call followed by collateral omission of unrelated rows that remained unarchived. This may be a cache/index invalidation or legacy sidebar projection regression related to, but stronger than, the existing behavior in this issue.
DoomDeity commentedon Aug 6, 2026
Follow-up reproduction (Windows Codex Desktop 26.730.8199.0): after closing/reopening the app, the same five local-project threads disappeared again from the sidebar/list while their rollout files, SQLite rows, archived=0, pinned=0, project assignments, and persisted sidebar order were intact. The five affected legacy threads shared one index condition: both first_user_message and preview were empty because the first user request arrived through the pasted-text attachment wrapper. Their actual request content and rollout history were present. Before repair, thread/list omitted exactly those records; after repopulating only those two derived index fields from the existing local attachment text, thread/list returned all five and their project IDs resolved correctly again. This points to a legacy attachment-first-message indexing/sidebar projection bug, distinct from the earlier unauthorized archive workflow error. No private project content or full logs are included here.