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

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:

1. With the app closed, I stripped the \\?\ prefix from all threads.cwd values (backed up DB first). Result: 0 prefixed rows, folders would match.
2. 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.
3. 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?

1. 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).
2. Open the sidebar: affected folders show "No chats".
3. 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.
4. Strip the prefix (update threads set cwd = substr(cwd, 5) where cwd like '\\?\%') → chats reappear in their folders.
5. 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