Repository navigation
Windows Desktop: API-login threads disappear from sidebar after restart, but still exist locally #19345
Description
Version
Codex Desktop on Windows (MSIX / Microsoft Store)
App package version:
26.422.2437.0
Thread/session metadata also shows:
cli_version: 0.124.0-alpha.2
Bug
When using API login in Codex Desktop on Windows, conversation threads disappear from the left sidebar after restarting the app.
This does not appear to be actual data loss.
Expected behavior
API-login conversations should remain visible in the left sidebar after restart, similar to account / ChatGPT login.
Actual behavior
After restarting Codex Desktop:
- API-login threads disappear from the left sidebar
- pinned or currently opened threads can still display normally
- account / ChatGPT login history behaves normally
What I verified
The threads still exist locally:
C:\Users\Administrator\.codex\sessions\...C:\Users\Administrator\.codex\session_index.jsonlC:\Users\Administrator\.codex\state_5.sqlite
I confirmed that affected threads still have:
- rollout/session files on disk
- index entries in
session_index.jsonl - rows in
state_5.sqlitewitharchived = 0
So this looks like a sidebar thread-list restoration / visibility issue, not conversation deletion.
Repro steps
- Open Codex Desktop on Windows
- Sign in with API login
- Start one or more conversations
- Close Codex Desktop completely
- Reopen Codex Desktop
- Observe that the API-login threads are missing from the left sidebar
Notes
I also tried clearing app-local package data under:
C:\Users\Administrator\AppData\Local\Packages\OpenAI.Codex_2p2nqsd0c76g0
That did not fix the issue.
Example affected thread id:
019dbec3-6c63-7ac0-878f-9ed85eb5bcf5
Activity
github-actions commentedon Apr 24, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Wangnov commentedon May 22, 2026
If the missing threads still exist in
state_5.sqlite/ rollout JSONL files, one thing worth checking is whether the local history is split across differentmodel_providerbuckets.I maintain an unofficial helper for that specific case: https://github.com/Wangnov/codex-threadripper
Start with the read-only diagnostic first:
If it shows threads split across providers,
codex-threadripper synccan reconcile the local metadata so Codex Desktop /codex resume/ app-server clients see the same history again. It writes backups before changing local state, but I would still back up~/.codexfirst.Caveat: this only targets provider-bucket visibility drift. If the root cause is sidebar cache/state, workspace path normalization, or encrypted-content ownership across accounts, it may not fix the underlying issue.