Skip to content

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

Open
Open
Windows: sidebar shows 'No chats' in project folders because cloud sync rewrites threads.cwd with \\?\ extended-length prefix#27243
Labels
appIssues related to the Codex desktop appbugSomething isn't workingsessionIssues involving session (thread) management, resuming, forking, naming, archivingwindows-osIssues related to Codex on Windows systems

Description

@Rolandval
Rolandval
opened on Jun 9, 2026

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

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    sessionIssues involving session (thread) management, resuming, forking, naming, archiving
    on Jun 9, 2026

  2. github-actions commented on Jun 9, 2026

    @github-actions
    github-actionsbot
    on Jun 9, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. takush74 commented on Jun 10, 2026

    @takush74
    takush74
    on Jun 10, 2026 – with ChatGPT Codex Connector

    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:

    1. Several existing project chats disappeared from their project folders after the update, while the threads still existed locally.
    2. 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>.
    3. After normalizing local sidebar/project metadata and thread state, the project chats reappeared.
    4. 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.

  4. Elvis-Christian commented on Jun 11, 2026

    @Elvis-Christian
    Elvis-Christian
    on Jun 11, 2026 – with ChatGPT Codex Connector

    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.

  5. wbuchser commented on Jun 11, 2026

    @wbuchser
    wbuchser
    on Jun 11, 2026

    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.

  6. onodanaoto-main commented on Jul 12, 2026

    @onodanaoto-main
    onodanaoto-main
    on Jul 12, 2026

    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.

  7. VirgilMing commented on Sep 10, 2026

    @VirgilMing
    VirgilMing
    on Sep 10, 2026 – with ChatGPT Codex Connector

    Adding a current cross-platform SSH reproduction that appears to hit the same exact-string project/thread matching bug, but with the simplest Windows path-equivalence case: / vs \.

    Environment:

    • Codex Desktop: 26.901.51231
    • Desktop host: Gentoo Linux x86_64
    • SSH remote host: Windows
    • Remote Codex CLI/app-server: 0.154.0
    • Connection itself is healthy: SSH, WebSocket upgrade, app-server initialize, and thread/list all succeed.

    Observed path representations for the same remote project:

    saved remote project path:
C:/Users/<user>/<project>

remote thread cwd / imported catalog cwd:
C:\Users\<user>\<project>

    The remote app-server has 65 unarchived threads; 56 belong to this project. The Linux Desktop's local_thread_catalog has already synchronized all 65 rows, including all 56 project threads, and its sync state reports the initial build complete. Nevertheless the project sidebar shows No chats.

    A read-only comparison against the Desktop catalog isolates the mismatch:

    exact cwd = C:/Users/<user>/<project>   -> 0 rows
exact cwd = C:\Users\<user>\<project> -> 56 rows

    The remote app-server itself is not the failing layer: issuing thread/list with either the forward-slash or backslash spelling of the Windows cwd returns the same 56 project threads.

    I also inspected the currently running Desktop bundle. The remote-project sidebar path feeds the saved project path into cwdValues; the local thread catalog query's exact_cwd branch ultimately performs an exact SQL string match of the form:

    cwd IN (SELECT value FROM json_each(?))

    The imported catalog row preserves the remote thread's raw cwd, so the two equivalent Windows spellings never compare equal. The prefix query path has the same representation problem.

    Additional control observations:

    • A pinned thread from the affected remote project still opens because it is hydrated by thread ID rather than by the project-cwd filter.
    • Another non-visible thread can also be read directly by ID.
    • This is therefore project grouping/filtering, not thread loss or failed remote synchronization.

    This is related to #30808 (SSH remote project path identity), but does not require symlinks, realpath differences, mapped drives, UNC paths, or the \\?\ prefix. A separator-only difference is sufficient.

    One implementation detail seems important for the fix: because the Desktop client here runs on Linux while the remote filesystem is Windows, path normalization cannot safely depend only on the client's native path semantics (for example, blindly using the local platform's path.normalize). Project/thread identity needs to use the remote host's path semantics, or a normalized/canonical project identity supplied by the remote app-server.

    At minimum, for Windows SSH hosts, C:/foo/bar and C:\foo\bar should compare as the same project path before exact_cwd / prefix filtering is applied.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingsessionIssues involving session (thread) management, resuming, forking, naming, archivingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions