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.
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
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)
Case 2: local drive (does not reproduce)
What is the expected behavior?
Additional information
Additional observations
State files still contain the thread
Even after the thread disappears from the Codex app UI:
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.