›_ Codex Issues
Codex Issues / #13846

Windows app: threads disappear after restart when project is on a mapped network drive (possible //?/unc/... path normalization issue)

Open 💬 8 comments Opened Mar 7, 2026 by takeval0907-ops
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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)

  1. Create a new project in the Codex app using a folder on a mapped network drive (W:).
  2. Create a new thread inside that project.
  3. Close the Codex app.
  4. Reopen the Codex app.
  5. The thread is no longer shown in the project.

Case 2: local drive (does not reproduce)

  1. Create a new project in the Codex app using a folder on a local drive (D:).
  2. Create a new thread inside that project.
  3. Close the Codex app.
  4. Reopen the Codex app.
  5. 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.

View original on GitHub ↗

8 Comments

github-actions[bot] contributor · 4 months ago

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

  • #13713
  • #13845
  • #12350

Powered by Codex Action

ofek · 4 months ago

I made a tracking issue for the root cause of these classes of bugs https://github.com/openai/codex/issues/10347

spl1974 · 4 months ago

I have the same problem. Files stored on network folder. https://github.com/openai/codex/issues/15052

Snow-wonS · 4 months ago

Same issue here. Can reproduce.

masa6161 · 3 months ago

Same here, and I can reproduce this issue in the Codex app version 26.325.3894.0 in Win11.
Details are below:

Environment

  • Codex Desktop 26.325.3894.0
  • Windows 11 Edu, 25H2
  • Workspace on a mapped network drive
  • Example:
  • mapped path: Z:\Experiment_scripts\exp1
  • UNC path: \\nas1\home\Experiment_scripts\exp1

What I observed

  • If I open the workspace via the mapped drive path (Z:\...), create/use threads, then fully quit and restart Codex Desktop, the thread history for that workspace is no longer shown.
  • The thread data is not actually lost.
  • If I then add/open the exact same physical directory via the UNC path (\\ nas1\home\...), the previously "missing" threads appear immediately.
  • At that point, the 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.sqlite still contains the threads.
  • In my case, the threads.cwd values in state_5.sqlite are stored as a UNC/device-style path:
  • \\?\UNC\ nas1\home\Experiment_scripts\exp1
  • Meanwhile, ~/.codex/.codex-global-state.json keeps workspace-root entries such as:
  • Z:\Experiment_scripts\exp1
  • So the app appears to be storing/comparing the same workspace in two different path forms and then treating them as different projects after restart.

Very strong repro summary

  1. Open workspace as Z:\...
  2. Use/create threads
  3. Quit Codex Desktop
  4. Reopen Codex Desktop
  5. History under Z:\... is empty
  6. Add the same directory as \\ nas1\home\...
  7. Existing history appears under the UNC workspace immediately

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 · 3 months ago

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:

  • Threads originally started from the mapped-drive workspace (Z:\...) appear under the UNC workspace after app restart.
  • But when I click one of those old threads to reopen it, that thread disappears from the UNC workspace and shows up under the mapped-drive workspace (Z:\...).
  • In contrast, threads newly created from the UNC workspace stay under the UNC workspace even after I reopen/select them.

So the behavior is not random:

  • old threads created under mapped-drive path migrate back to mapped-drive workspace when selected
  • new threads created under UNC path remain under UNC workspace when selected

This strongly suggests Codex is using different path sources for:

  1. initial history grouping on startup
  2. workspace binding when reopening a thread

Local state appears consistent with that theory:

  • state_5.sqlite stores thread cwd as a device/UNC path such as:

`\\?\UNC\nas1\home\Experiment_scripts\exp1

  • older rollout/session metadata for old threads records:

`Z:\Experiment_scripts\exp1

  • newer rollout/session metadata for threads created from the UNC workspace records:

`\\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 · 3 months ago

do it this and solve ok on windwows or similar for mac/linux

setx CODEX_HOME 'C:\Users\your_user\.codex'

Darkaxt · 3 months ago

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:

  • the rollout/session JSONL files were still present under %USERPROFILE%\\.codex\\sessions\\...
  • raw session metadata still showed the user-facing mapped path, e.g. T:\\...
  • but state_5.sqlite -> threads.cwd had drifted to a Windows device/UNC form like:

\\?\\UNC\\tresoritdrive_<redacted>.drive.tresorit.com\\Tresorit Drive(<redacted>)\\...

  • once that happened, the old threads no longer matched the new/stable local project entries

So in my case this was not data loss. It was a path-identity mismatch between:

  • rollout/session metadata: T:\\...
  • thread index in SQLite: \\?\\UNC\\...
  • desired stable project root: local C:\\Users\\<redacted>\\Documents\\Projects\\...

I reproduced/recovered this across 4 separate workspaces. The recovery that worked for me was:

  1. Create stable local roots under C:\\Users\\<redacted>\\Documents\\Projects\\...
  2. Back up %USERPROFILE%\\.codex\\state_5.sqlite
  3. Rewrite only the affected threads.cwd rows from old UNC / T: roots to the stable local roots
  4. Reopen Codex and recreate the visible project entries if needed

After doing that, the old history became visible again.

Useful extra detail: fixing threads.cwd was 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 besides threads.cwd.

This feels like the same family of Windows path canonicalization bugs already discussed here, but with a concrete recovery path:

  • mapped drive form: T:\\...
  • resolved device/UNC form: \\?\\UNC\\...
  • stable local form: 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.