Windows Desktop: Project Timeline shows no history despite existing threads (path identity mismatch with OneDrive/GoodSync/junction/\\?\ prefix) #18253

Activity

1. Janzstone

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Apr 17, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   sessionIssues involving session (thread) management, resuming, forking, naming, archivingIssues involving session (thread) management, resuming, forking, naming, archiving

   on Apr 17, 2026
3. github-actions commented on Apr 17, 2026

   

   github-actionsbot

   on Apr 17, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Windows app: older local threads disappear from sidebar and sidebar search after restart while still present on disk #17540
   • Desktop thread panel hides existing workspace threads after workspace restructuring; backend pagination still returns them #16901
   • Codex desktop on Windows reports malformed cwd for worktree threads and can target the wrong checkout #16525
   • Multiple sidebar bugs after workspace directory migration: "56 years ago" timestamps, missing threads, threads vanish on click (macOS) #17317

   Powered by Codex Action
4. Janzstone commented on Apr 17, 2026

   

   Janzstone

   on Apr 17, 2026

   Author

   More actions

   Post-launch evidence from the latest desktop bundle still points to a thread-listing/state-db problem.

   Environment:

   • Latest launched desktop bundle identified itself in logs as Codex Desktop 26.415.20818.
   • Evidence collected on April 16, 2026 between 11:20 PM and 11:23 PM America/Toronto, immediately after relaunch.

   What I observed after launch:

   • The app successfully handled thread/start, thread/resume, and repeated thread/list requests.
   • Local state was not empty:
     • threads table count: 35
     • session_index.jsonl entries: 35
     • non-archived threads: 35
   • A brand-new thread created after relaunch was persisted, which shows the app can still write fresh state.

   What still fails:

   • During thread/list, the app repeatedly logged:
     • state db discrepancy during read_repair_rollout_path: upsert_needed (fast path)
     • state db read-repair upsert failed ... error returned from database: (code: 779) database disk image is malformed
     • state db reconcile_rollout upsert failed ... error returned from database: (code: 779) database disk image is malformed
   • Those warnings were emitted multiple times after launch, not just once during an old migration.

   Why this seems important:

   • The on-disk inventory is present and populated, but the bundle is still attempting read-repair during thread/list and hitting a malformed-database error.
   • That suggests the missing-thread symptom is not simply “no thread records exist”; it looks more like the thread-list/read-repair path is being derailed by a corrupted row/index/page in the state DB.
   • The persisted repo associations also still show mixed identities for repos whose final directory begins with ne…, which may be part of why read-repair keeps running, but the stronger signal is the repeated SQLite corruption error during thread/list.

   Files checked locally:

   • state_5.sqlite
   • session_index.jsonl
   • logs_2.sqlite

   If helpful, I can next provide a minimal repro-oriented dump of just:

   • the count of affected thread/list warnings after launch
   • the exact SQLite error frequency
   • whether deleting/rebuilding only the thread-list derived state avoids the malformed-database path