›_ Codex Issues
Codex Issues / #18253

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

Open 💬 3 comments Opened Apr 17, 2026 by Janzstone
💡 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 (From “About Codex” dialog)?

26.415.20818

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Project Timeline in Codex Desktop shows no history, even though thread/session history exists on disk.

What steps can reproduce the bug?

  1. Use Codex Desktop on Windows with workspace under OneDrive-backed path.
  2. Open project via C:\Users\jacob\GoodSync\repos\net_80_migration (junction form).
  3. After restarts/path normalization attempts, Timeline becomes empty.
  4. Data still exists:
  • ~/.codex/sessions/**/rollout-*.jsonl contains session_meta entries.
  • ~/.codex/state_5.sqlite contains threads rows.

What is the expected behavior?

Timeline should show existing thread history for the project regardless of equivalent Windows path forms.

Additional information

What do you see instead?

Timeline is empty. Internally, path identity drifts across:

  • C:\Users\jacob\GoodSync\...
  • C:\Users\jacob\OneDrive\GoodSync\...
  • \\?\C:\Users\jacob\OneDrive\GoodSync\...

Additional information

Evidence from local inspection before restore:

  • session_meta_entries: 32
  • threads_total: 32
  • session_meta cwd mostly C:\Users\jacob\GoodSync\repos\...
  • DB threads.cwd mostly \\?\C:\Users\jacob\OneDrive\GoodSync\repos\...
  • C:\Users\jacob\GoodSync is a junction targetting C:\Users\jacob\OneDrive\GoodSync

This looks like a Windows path canonicalization/path-equivalence bug in project timeline matching.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 4 months ago

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

  • #17540
  • #16901
  • #16525
  • #17317

Powered by Codex Action

Janzstone · 4 months ago

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
shleder · 11 days ago

This is a useful path-identity vs persisted-history case for codex-rescue==0.1.0a4: the rollouts/threads exist, but equivalent Windows path forms break project timeline matching.

If the affected state still exists, could you run a read-only check:

pipx install codex-rescue==0.1.0a4
codex-rescue sessions
codex-rescue doctor --latest

It won’t normalize OneDrive/junction/\\?\ paths in Desktop, but it can independently verify the durable session inventory and whether the underlying rollouts are healthy while project association is broken.

Please share only sanitized status/findings/counts—no raw rollouts, SQLite DBs, prompts, tool output, credentials, repository data, thread IDs, or private paths.