Windows: sidebar shows 'No chats' in project folders because cloud sync rewrites threads.cwd with \\?\ extended-length prefix

Open 💬 5 comments Opened Jun 9, 2026 by Rolandval

💡 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?

Latest as of 2026-06-09 (auto-updated; ~/.codex/version.json reports latest_version: 0.138.0)

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Windows 11 Pro 10.0.26200

What issue are you seeing?

Most project folders in the Codex Desktop sidebar show "No chats" even though the chats still exist. This looks like the same symptom as #20741 and #23193, and I believe I found the root cause on Windows, with a reproducible local diagnosis.

Root cause: the sidebar groups chats into project folders by exact string match on threads.cwd in ~/.codex/state_5.sqlite. For 334 of my 677 threads, cwd is stored with the Windows extended-length path prefix:

\\?\C:\Users\<user>\Projects\YouTube     <- stored in threads.cwd
C:\Users\<user>\Projects\YouTube         <- project root the sidebar groups by

The strings never match, so the folder renders "No chats" while the threads are intact (rollout JSONL files exist under ~/.codex/sessions/... and are listed in ~/.codex/session_index.jsonl). Notably, the session_meta / turn_context records inside the rollout files contain the plain cwd without the prefix — only the SQLite threads.cwd column has the prefixed form.

The prefix is re-introduced by cloud sync at every app launch. I verified this:

With the app closed, I stripped the \\?\ prefix from all threads.cwd values (backed up DB first). Result: 0 prefixed rows, folders would match.
On the next app launch, exactly the ~100 most recent threads with source = 'vscode' (many with thread_source = 'user') got their cwd rewritten back to the \\?\-prefixed form, with updated_at equal to the launch time. No local file in ~/.codex contains the prefixed paths for those threads, so the values must come from server-side thread metadata recorded at session creation time.
Stripping the prefix again after the startup sync completes makes all folders show their chats immediately — until the next app restart re-breaks the ~100 recent threads.

This is likely the same path-normalization family of bugs as #24697 and #20517 (rollout path compared with and without the \\?\ prefix), but here it affects sidebar folder grouping and makes chats appear lost to users.

What steps can reproduce the bug?

On Windows, use Codex Desktop with several project folders that have chat history (threads created by some earlier CLI/app versions recorded the canonicalized \\?\ cwd).
Open the sidebar: affected folders show "No chats".
Inspect ~/.codex/state_5.sqlite: select cwd from threads where cwd like '\\?\%' returns many rows whose plain-path equivalents are exactly the project roots shown in the sidebar.
Strip the prefix (update threads set cwd = substr(cwd, 5) where cwd like '\\?\%') → chats reappear in their folders.
Restart the app → the most recent ~100 user threads are rewritten back to the prefixed form by startup sync and disappear from folders again.

What is the expected behavior?

Folder grouping should normalize Windows extended-length paths (\\?\C:\... ≡ C:\...) before matching, and/or
Sync should not overwrite a locally-normalized cwd with a stale prefixed variant.

Chats should never appear lost because of path canonicalization differences.

Additional information

Workaround for affected users (after the app has started and synced):

update threads set cwd = substr(cwd, 5) where cwd like '\\?\%';

on ~/.codex/state_5.sqlite — chats reappear instantly, but it must be re-run after every app restart.

Related: #20741, #23193, #24697, #20517

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 2 months ago

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

#26411
#26031

Powered by Codex Action

takush74 · 2 months ago

Additional minimal data point on Windows 26.608.

Environment:

Codex app About dialog: 26.608.12217
Windows AppX package: 26.608.1337.0
Expanded/bundled CLI: codex-cli 0.138.0-alpha.7
Platform: Windows

Observed behavior:

Several existing project chats disappeared from their project folders after the update, while the threads still existed locally.
Local state showed the same path-normalization pattern described here: project roots were effectively X:\<project> / saved workspace roots, while thread rows used Windows extended/UNC-style paths such as \\?\UNC\<server>\<share>\<project>.
After normalizing local sidebar/project metadata and thread state, the project chats reappeared.
Additional symptom: when opening one of the restored project chats from the project folder, that chat disappeared from the project’s chat list again during the same app session. Restarting Codex made it reappear. The underlying thread still existed, was unarchived, had the correct project cwd/hint, and could be read directly.

This looks related to the same sidebar/project grouping issue, with a possible in-memory/sidebar refresh bug after a restored thread is opened. No raw local paths or private project names included here.

Elvis-Christian · 2 months ago

Confirming that this issue also affects my Codex Desktop installation on Windows, specifically all projects backed by mapped network/SSHFS drives.

Environment:

Codex Desktop: 26.608.1337.0 (latest Microsoft Store version available to me on June 11, 2026)
Windows
Local project under C:\Users\...\Downloads displays its chats normally
Projects opened through mapped remote drives such as K:\, Z:\, W:\, and Y:\ display no chats when expanded

The missing chats are not lost:

Global search finds and opens them
state_5.sqlite passes PRAGMA integrity_check
The affected threads exist in the threads table

The path mismatch is clear in the local state. The Desktop sidebar stores project roots using mapped-drive paths such as K:\ and Z:\, while affected threads.cwd values use canonical extended UNC paths such as:

K:\ vs \\?\UNC\sshfs.r\...\opt\taktos\
Z:\ vs \\?\UNC\sshfs\...\

In one affected project, 25 existing threads were associated with the canonical UNC path while the sidebar project root was K:\. Manually changing threads.cwd to the mapped-drive path made the association work temporarily, but the running Desktop app rewrote some values back to canonical UNC paths within seconds.

This makes continuity very difficult for users working with remote repositories, NAS shares, SSHFS mounts, mapped drives, junctions, or other equivalent Windows path forms. The project-thread lookup should compare normalized path identities rather than literal path strings.

wbuchser · 2 months ago

Additional Windows data point:

Environment:

Codex Desktop 26.608.1337.0
Bundled CLI: codex-cli 0.138.0-alpha.7
Windows 11, build 10.0.26200

Observed on two machines after the 26.608 update:

Projects on aliased Windows paths lose chats from the sidebar/project list.
Projects on plain local C:\... paths appear normal.
One affected machine uses a mapped network drive path, e.g. R:\..., backed by a UNC path.
Another affected workspace uses a local subst drive path, e.g. B:\..., backed by a local absolute path.
Exact local/UNC paths are omitted for privacy.

Observed behavior:

Project folders remain visible, but non-archived chats disappear or show as missing.
In one project, clicking a visible chat opens the conversation on the right but removes it from the project list on the left. After a delay/restart/re-login, it can reappear.
The chats do not appear deleted; local state still contains active threads.
Local diagnosis suggests different Codex layers disagree on path identity: sidebar/listing may use the alias path, while thread read/state may use the resolved path.

This looks like the same path-normalization/sidebar grouping bug described here, with the extra note that it affects local subst drive aliases as well as mapped network-drive/UNC paths.

onodanaoto-main · 1 month ago

I submitted the issue through the in-app feedback flow.

Feedback ID:
019f53e9-3c40-7521-93d8-1af755e058f5

Please associate this feedback with my support request and escalate it to the Codex Desktop engineering team. The report includes the recurring sidebar disappearance, Remote SSH details, and the symbolic-link versus physical cwd mismatch.