Skip to content

Codex Desktop on Windows no longer shows older chats after update #23193

Open
Open
Codex Desktop on Windows no longer shows older chats after update#23193
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

@Explorersoft
Explorersoft
opened on May 17, 2026

In-app feedback ID: 019e3780-31aa-7b70-b26e-57b4f40e5b56

After updating Codex Desktop on Windows, many older chats disappeared from the sidebar/project views and are not found by in-app search.

The data still exists locally:

  • ~/.codex/state_5.sqlite contains the missing threads
  • ~/.codex/sessions contains the JSONL session files
  • Threads are active, not archived

Examples:

  • HealthAgents shows only 3 chats, but local state has 38 active threads for that cwd
  • ZONE-koop shows only 2-3 chats, but local state has 19 active threads
  • Restarting Codex and rebooting Windows did not fix it

Possible cause:
Some thread cwd values are stored as \?\D:... while project roots are D:...
The UI/sidebar/search may not be normalizing Windows extended-length paths consistently.

Environment:

  • Windows
  • Codex Desktop: OpenAI.Codex_26.513.4821.0_x64__2p2nqsd0c76g0
  • App/server version in sessions: 0.131.0-alpha.9

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 May 17, 2026

  2. github-actions commented on May 17, 2026

    @github-actions
    github-actionsbot
    on May 17, 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. Explorersoft commented on May 17, 2026

    @Explorersoft
    Explorersoft
    on May 17, 2026
    Author

    Clarification: the affected cwd paths include Windows extended-length path prefixes like:

    \?\D:\HealthAgents\site
    \?\D:\SIS-ZONE\CodeX\koop

    while the saved project roots appear as normal paths like:

    D:\HealthAgents\site
    D:\SIS-ZONE\CodeX\koop

  4. Explorersoft commented on May 17, 2026

    @Explorersoft
    Explorersoft
    on May 17, 2026
    Author

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

    Powered by Codex Action

    I reviewed the suggested possible duplicates.

    Related but not exact duplicates:

    My issue differs because the affected threads are not just failing to resume/open. Most of them are not surfaced in the sidebar/project views or in-app search at all, even though state_5.sqlite still contains active rows and the rollout JSONL files exist.

    So this may share the same underlying history/path/index regression, but the user-facing failure mode here is listing/search visibility.

  5. pseudico commented on May 19, 2026

    @pseudico
    pseudico
    on May 19, 2026 – with ChatGPT Codex Connector

    I am seeing the same class of bug on Windows, with current local diagnostics.

    Environment:

    • Platform: Windows, x64
    • Codex executable/product version: 0.131.0-alpha.9
    • Observed date: 2026-05-19
    • Local storage checked: %USERPROFILE%\.codex\state_5.sqlite, %USERPROFILE%\.codex\session_index.jsonl, %USERPROFILE%\.codex\.codex-global-state.json

    User-visible behavior:

    • The Desktop sidebar still lists saved projects, but several projects display No chats even though they have unarchived local thread rows.
    • One highly active project dominates the visible recent/project list; older or less recently active project histories are effectively pushed out of the sidebar.
    • Sidebar options such as Show all chats, Organize -> Chronological list, and project Show more did not restore the missing project histories.
    • This makes the app look like project history has been wiped, but the local data is still present.

    Read-only local evidence:

    • state_5.sqlite contains many unarchived thread rows for projects that are missing or incomplete in the sidebar.
    • Representative active/unarchived counts by sanitized project/root group:
      • Project A: ~410 active rows across equivalent Windows path forms
      • Project B: 74 active rows
      • Project C: 47 active rows
      • Project D: 24 active rows
      • Project E: 14 active rows
    • Several cwd values are stored in both plain and Windows extended-length forms, e.g. C:\... and \\?\C:\....
    • session_index.jsonl also contains recent thread IDs that are not surfaced consistently by the Desktop project sidebar.

    Expected behavior:

    • Each visible saved project should show its own unarchived local threads, or provide reliable project-specific pagination/loading.
    • A project should not show No chats when state_5.sqlite and session metadata still contain unarchived threads for that project/root.
    • The Desktop app should normalize equivalent Windows paths (C:\... vs \\?\C:\...) before grouping threads by project.
    • There should be a supported repair/reindex action for rebuilding the sidebar/project grouping from durable local state.

    Actual behavior:

    • The sidebar appears to rely on a limited or stale recent/global thread subset and/or path-sensitive project grouping.
    • Reopening/resuming hidden threads via lower-level mechanisms is possible, but that does not restore the user's requirement: seeing all threads inside their projects in the Desktop sidebar.

    A screenshot from the affected sidebar shows multiple saved projects where some show No chats despite local rows existing, while another active project shows only a recent subset. I cannot attach the screenshot through the connector used to post this comment, but it is available if helpful.

    This seems closely aligned with #18640, #20833, #21128, #21581, #22796, and this issue, but I wanted to add a current Windows + 0.131.0-alpha.9 data point with project grouping/path-normalization evidence.

  6. rallek commented on May 26, 2026

    @rallek
    rallek
    on May 26, 2026

    I’m seeing a very similar issue on Windows Codex Desktop.

    Symptom:

    • Project list is visible.
    • Most projects show “No chats”.
    • Only two currently active projects still show chats.
    • The missing sessions are not deleted.

    Local verification:

    • %USERPROFILE%\.codex\state_5.sqlite passes PRAGMA integrity_check = ok.
    • threads table contains 133 rows.
    • archived = 0 for all 133 rows.
    • Every threads.rollout_path points to an existing rollout-*.jsonl file.
    • codex resume --all in Codex CLI shows the missing sessions correctly.
    • Direct resume by thread id also works.
    • Exporting the rollout-*.jsonl files to Markdown recovered readable transcripts.

    Observed Desktop state:

    • .codex-global-state.json still contains electron-saved-workspace-roots for the affected projects.
    • project-order only contains a subset of projects.
    • heartbeat-thread-permissions-by-id contained only 7 thread ids, all belonging to currently visible sessions.
    • I tested adding missing permission entries for all 133 DB threads using the same sandbox policy shape as existing entries, but this did not make the Desktop UI show the missing sessions.
    • I rolled this change back.

    Counts:

    • DB threads: 133
    • Existing rollout files: 133
    • Archived threads: 0
    • CLI-visible sessions via codex resume --all: yes
    • Desktop-visible sessions: only a small subset

    This looks like a Windows Desktop sidebar/project indexing or workspace mapping issue, not data loss. The CLI can still see and resume the sessions.

    A built-in repair/reindex action from state_5.sqlite + sessions/**/*.jsonl would be very helpful.

  7. huajiexiewenfeng commented on May 31, 2026

    @huajiexiewenfeng
    huajiexiewenfeng
    on May 31, 2026 – with ChatGPT Codex Connector

    I ran into a similar Windows-side Codex Desktop update issue: older chats were still present locally, but the new UI/sidebar did not show them under the expected project.

    I documented the recovery workflow I used here:

    https://github.com/huajiexiewenfeng/codex-session-recovery

    This is an unofficial workaround, not an upstream fix. It does a dry-run first, checks session_index.jsonl, .codex-global-state.json, SQLite threads.cwd, exact cwd matching, and Windows \\?\ path mismatches, then creates timestamped backups before any write and verifies the result afterward.

    It may help if the missing threads still exist in state_5.sqlite and sessions/**/*.jsonl, but the Desktop app no longer associates them with the project after an update.

  8. Donkodio commented on May 31, 2026

    @Donkodio
    Donkodio
    on May 31, 2026

    I ran into the same general failure mode on macOS: Codex Desktop showed "No chats" for projects even though the local SQLite thread store still had active threads and PRAGMA integrity_check returned OK.

    In my case, the strongest clue was that pinned chats were still visible. That made it possible to recover visibility by treating this as a sidebar/project index issue rather than data loss.

    The workaround I used was:

    • rebuild thread-workspace-root-hints from threads.cwd in ~/.codex/state_5.sqlite;
    • rebuild sidebar project/chat ordering in .codex-global-state.json;
    • use pinned-thread-ids as a fallback for important real project chats;
    • archive service automation/subagent threads so the sidebar is not flooded with background runs.

    I published a sanitized helper and recovery notes here:
    https://github.com/Donkodio/codex-desktop-sidebar-recovery

    The helper defaults to dry-run, creates backups before applying changes, and does not upload local data. No raw sessions, tokens, .env, private keys, Telegram sessions, proxy credentials, or private chat dumps are included.

  9. rallek commented on Jun 1, 2026

    @rallek
    rallek
    on Jun 1, 2026

    Additional short update from my Windows case, building on the helpful recovery notes from @huajiexiewenfeng and @Donkodio:

    What I tried first:

    • verified that state_5.sqlite is OK
    • verified that all rollout-*.jsonl files still exist
    • verified that codex resume --all shows the missing sessions
    • tested huajiexiewenfeng/codex-session-recovery
    • fixed Windows \\?\ cwd mismatches and rebuilt project/sidebar hints for affected projects
    • used surface_codex_sidebar_threads.py to make selected chats visible again

    New observation:

    After making some progress, I noticed that some previously visible chats suddenly disappeared from the Desktop sidebar again.

    Then I archived some chats/projects that I currently do not need. Immediately afterward, other previously missing non-archived chats became visible again.

    So this now looks like a Desktop sidebar visibility/surface limit rather than data loss. In my case, roughly 49 chats seem to be visible at the same time. When too many chats compete for the sidebar, some projects show “No chats” even though their sessions still exist and are resumable via CLI.

    Practical workaround:

    Archive chats/projects you do not currently need. This may make other missing non-archived chats visible again.

    The “No chats” label is therefore misleading: it can mean “no chats currently surfaced in the sidebar”, not “no local chats exist”.

    Is this intended behavior, or is it a bug?

  10. mgdark-commits commented on Jun 1, 2026

    @mgdark-commits
    mgdark-commits
    on Jun 1, 2026 – with ChatGPT Codex Connector

    Short Windows update from another reproduction of this issue.

    A copied-app renderer workaround restored hidden project chats on Windows AppX OpenAI.Codex_26.527.7698.0 / codex-cli 0.136.0-alpha.2 without editing state_5.sqlite, session_index.jsonl, or rollout files.

    The workaround patches only a copied app\resources\app.asar, not C:\Program Files\WindowsApps\OpenAI.Codex_*, and changes the initial sidebar refresh from the limited global recent slice to the existing all-thread pagination helper:

    // original
let t=await this.listRecentThreads({limit:50*this.recentConversationPageCount,cursor:null});

// copied-app workaround replacement; trailing spaces preserve byte length
let t={data:await this.listAllThreads({modelProviders:null,archived:!1}),nextCursor:null};

    Detailed Windows notes: #25500 (comment)

    This is only an unsupported diagnostic workaround. It reinforces that the hidden chats are usually still local/readable, and that the real fix should be project-scoped pagination/loading by cwd instead of rendering each project from only the already-loaded global recent window.

  11. ghatk047 commented on Jun 4, 2026

    @ghatk047
    ghatk047
    on Jun 4, 2026

    Affected on macOS, version 26.601.21317. All projects show "No chats" except ones opened fresh after the June 2 update. Data is confirmed intact in state_5.sqlite (486 active threads, all hints correct, session_index complete). Manually opening projects does not trigger re-indexing. This appears to be a sidebar rendering bug introduced in this release.

  12. wangyaok1 commented on Jun 7, 2026

    @wangyaok1
    wangyaok1
    on Jun 7, 2026 – with ChatGPT Codex Connector

    Hi everyone, I'm tracking the same Codex Desktop missing-thread/sidebar-history issue on macOS.

    For those affected here: did you eventually get all hidden project threads back in Desktop? If yes, what exact method worked durably for you?

    Examples I'm trying to distinguish:

    • official update fixed it
    • restart/reindex fixed it
    • codex resume --all <thread-id> rehydrated it
    • repairing session_index.jsonl / state_5.sqlite / .codex-global-state.json fixed it
    • Codex Wake or another local recovery helper fixed it
    • app bundle / listAllThreads patch fixed it
    • nothing worked yet

    In my case, the missing project threads still exist in ~/.codex/sessions and state_5.sqlite, but Desktop does not hydrate them back into the project sidebar after restart. Any confirmed durable fix would help. Please do not share private session contents; sanitized method/results are enough.

  13. wangyaok1 commented on Jun 10, 2026

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

    Adding a macOS datapoint after updating to the latest Desktop build.

    Environment:

    • macOS 15.5 (24F74)
    • Apple Silicon / arm64
    • Codex Desktop: 26.608.12217
    • CFBundleVersion: 3722
    • Local storage: default ~/.codex

    Recovery status on my affected project:

    • The update appears to have restored some previously missing threads.
    • It did not restore everything.
    • Older project threads are still missing from the Desktop sidebar/project history.
    • The local data still appears to exist. For the affected project, state_5.sqlite still has 251 active/non-archived rows with the expected project cwd.
    • Earlier checks also confirmed matching rollout JSONL/session files under ~/.codex/sessions.

    So my current result is: 26.608.12217 looks like a partial recovery, not a full recovery. It would still be very helpful to have an official full local reindex/recovery command that rebuilds sidebar/project history from durable local state.

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