Repository navigation
Windows app: threads disappear after restart when project is on a mapped network drive (possible //?/unc/... path normalization issue) #13846
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.305.950.0
What subscription do you have?
ChatGPT plus
What platform is your computer?
Windows10
What issue are you seeing?
Body
I found a reproducible issue in the Windows Codex app where threads disappear from the project view after restarting the app, but only when the project is created on a mapped network drive.
Environment
- Codex app on Windows
- VS Code Codex extension on Windows
- Both are running natively on Windows (not WSL)
- Project roots tested on:
- mapped network drive: W:... (NAS-backed drive)
- local drive: D:...
Summary
If I create a project and thread on a mapped network drive (W:), the thread disappears from the Codex app after restart.
However, the thread data still appears to exist in local Codex state files.
The same behavior does not reproduce when using a local drive (D:).
What steps can reproduce the bug?
Case 1: mapped network drive (reproduces)
- Create a new project in the Codex app using a folder on a mapped network drive (W:).
- Create a new thread inside that project.
- Close the Codex app.
- Reopen the Codex app.
- The thread is no longer shown in the project.
Case 2: local drive (does not reproduce)
- Create a new project in the Codex app using a folder on a local drive (D:).
- Create a new thread inside that project.
- Close the Codex app.
- Reopen the Codex app.
- The thread is still shown normally.
What is the expected behavior?
Additional information
Additional observations
- The issue reproduces even without involving VS Code.
- I initially suspected Japanese folder names, but after testing:
- Japanese path + mapped network drive (W:) -> reproduces
- Japanese path + local drive (D:) -> does not reproduce
- This suggests the main trigger is the mapped network drive / UNC path handling, not Japanese characters in the path by themselves.
State files still contain the thread
Even after the thread disappears from the Codex app UI:
- the prompt history remains in .codex/.codex-global-state.json
- the thread entry still exists in session_index.jsonl
So this does not look like thread data loss.
It looks more like the app fails to re-associate the saved thread with the project/workspace during startup.
Suspicious area
I noticed that .codex/cap_sid contains workspace_by_cwd entries like this for the network drive project:
{
"workspace_by_cwd": {
"//?/unc/server/share/path-with-japanese-chars/project-root": "S-1-5-21-..."
}
}I am not sure whether this is the cause, but it seems relevant that the mapped drive is represented internally as a UNC/device-style path.
One possible explanation is that the app may be resolving the same workspace path differently before and after restart (for example mapped drive path vs UNC/device path), which could cause the workspace/thread association to fail during restoration.
Activity
github-actions commentedon Mar 7, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
ofek commentedon Mar 8, 2026
I made a tracking issue for the root cause of these classes of bugs #10347
spl1974 commentedon Mar 18, 2026
I have the same problem. Files stored on network folder. #15052
Snow-wonS commentedon Mar 18, 2026
Same issue here. Can reproduce.
masa6161 commentedon Mar 31, 2026
Same here, and I can reproduce this issue in the Codex app version
26.325.3894.0in Win11.Details are below:
Environment
What I observed
Z:\...), create/use threads, then fully quit and restart Codex Desktop, the thread history for that workspace is no longer shown.\\ nas1\home\...), the previously "missing" threads appear immediately.Z:\...workspace entry remains empty, while the UNC workspace shows the real history.This makes the issue look very strongly like a workspace path canonicalization/equivalence bug rather than data loss.
Additional local evidence
~/.codex/state_5.sqlitestill contains the threads.threads.cwdvalues instate_5.sqliteare stored as a UNC/device-style path:\\?\UNC\ nas1\home\Experiment_scripts\exp1~/.codex/.codex-global-state.jsonkeeps workspace-root entries such as:Z:\Experiment_scripts\exp1Very strong repro summary
Z:\...Z:\...is empty\\ nas1\home\...Expected
The mapped-drive path and the equivalent UNC path should be treated as the same workspace for thread history and project association.
Actual
History is partitioned by path representation.
Current workaround
Using the UNC path directly avoids the issue in my environment.
masa6161 commentedon Mar 31, 2026
Additional detail from further testing:
The workspace-switching behavior seems to depend on which path form was used when the thread was originally created.
What I now observe:
Z:\...) appear under the UNC workspace after app restart.Z:\...).So the behavior is not random:
This strongly suggests Codex is using different path sources for:
Local state appears consistent with that theory:
state_5.sqlitestores threadcwdas a device/UNC path such as:`\?\UNC\nas1\home\Experiment_scripts\exp1
`Z:\Experiment_scripts\exp1
`\nas1\home\Experiment_scripts\exp1
So the same underlying workspace is being represented in at least three forms:
Z:\...\\nas1\...\\?\UNC\nas1\...The app seems to partially canonicalize these in one code path but not another, which causes thread history to regroup differently depending on whether the thread was originally created from mapped-drive or UNC workspace.
These assumptions are discussed with and output by Codex!
marciocamello commentedon Apr 1, 2026
do it this and solve ok on windwows or similar for mac/linux
setx CODEX_HOME 'C:\Users\your_user.codex'
Darkaxt commentedon Apr 20, 2026
I hit the same class of bug on Windows with a Tresorit-backed mapped drive (
T:), and I was able to recover the hidden history locally.What I observed:
%USERPROFILE%\\.codex\\sessions\\...T:\\...state_5.sqlite->threads.cwdhad drifted to a Windows device/UNC form like:\\?\\UNC\\tresoritdrive_<redacted>.drive.tresorit.com\\Tresorit Drive(<redacted>)\\...So in my case this was not data loss. It was a path-identity mismatch between:
T:\\...\\?\\UNC\\...C:\\Users\\<redacted>\\Documents\\Projects\\...I reproduced/recovered this across 4 separate workspaces. The recovery that worked for me was:
C:\\Users\\<redacted>\\Documents\\Projects\\...%USERPROFILE%\\.codex\\state_5.sqlitethreads.cwdrows from oldUNC/T:roots to the stable local rootsAfter doing that, the old history became visible again.
Useful extra detail: fixing
threads.cwdwas enough to restore the underlying thread-to-workspace matching, but it was NOT enough to restore the project entries themselves. I still had to recreate the project entries in the UI. That makes me suspect there is a second project-list registry somewhere besidesthreads.cwd.This feels like the same family of Windows path canonicalization bugs already discussed here, but with a concrete recovery path:
T:\\...\\?\\UNC\\...C:\\Users\\...\\Documents\\Projects\\...If helpful, I can provide a redacted write-up of the exact before/after state and the row counts I updated.