Local Codex Desktop sessions disappear from sidebar after restart (Windows App)

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

• #11721
• #11997

Powered by Codex Action

Yeah this just happened to me, it got me a bit worried - luckily it seems data should be still in .codex directory, just the desktop app ignores them for some reason :(

Do you know if there is any workaround to get them back until they make an official fix?

Hi,

not really.
My only workaround is to pin important chats. Then they will appear again
after restart.

David Klingenberg @.***> schrieb am Mo., 16. März 2026,
11:44:

klinki left a comment (openai/codex#13713) <https://github.com/openai/codex/issues/13713#issuecomment-4066745761> Yeah this just happened to me, it got me a bit worried - luckily it seems data should be still in .codex directory, just the desktop app ignores them for some reason :( Do you know if there is any workaround to get them back until they make an official fix? — Reply to this email directly, view it on GitHub <https://github.com/openai/codex/issues/13713#issuecomment-4066745761>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFZMV5BA3CCPTFW32IM4UA34Q7LHJAVCNFSM6AAAAACWJHDF52VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DANRWG42DKNZWGE> . You are receiving this because you authored the thread.Message ID: @.***>

My issue was different after all. It was misconfigured CODEX_HOME - speckit changed that and I didn't notice. So luckily I have all data back :)

I have the same issue with Win 11

Is your project on the network path?
I have a feeling that's the problem.

Lukas @.***> schrieb am Mi., 18. März 2026, 07:19:

Lukas-EyeC left a comment (openai/codex#13713) <https://github.com/openai/codex/issues/13713#issuecomment-4080040762> I have the same issue with Win 11 — Reply to this email directly, view it on GitHub <https://github.com/openai/codex/issues/13713#issuecomment-4080040762>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFZMV5FEGBRKBEEQPQC42S34RI5XZAVCNFSM6AAAAACWJHDF52VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DAOBQGA2DANZWGI> . You are receiving this because you authored the thread.Message ID: @.***>

No - local windows path. Only one of three threads are visibile in the UI - but the sessions are present in sessions folder, they are present int the session_index.jsonl and also seem to exist in state_5.sqlite (at least mentioned - I just looked with a text editor into it). Codex 26.313.451514

Damn.
yeah same issue at my side.
Hope there will be a fix soon

Lukas @.***> schrieb am Mi., 18. März 2026, 07:32:

Lukas-EyeC left a comment (openai/codex#13713) <https://github.com/openai/codex/issues/13713#issuecomment-4080081416> No - local windows path. Only one of three threads are visibile in the UI - but the sessions are present in sessions folder, they are present int the session_index.jsonl and also seem to exist in state_5.sqlite (at least mentioned - I just looked with a text editor into it). Codex 26.313.451514 — Reply to this email directly, view it on GitHub <https://github.com/openai/codex/issues/13713#issuecomment-4080081416>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFZMV5DKISUNAU3HZ2FAJ7T4RI7GBAVCNFSM6AAAAACWJHDF52VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DAOBQGA4DCNBRGY> . You are receiving this because you authored the thread.Message ID: @.***>

I read through the current thread more closely, and the unresolved Windows report looks narrower than the earlier CODEX_HOME case.

• session_index.jsonl is not what decides sidebar visibility directly; thread/list goes through RolloutRecorder::list_threads(...) and only uses the session index for thread names.
• That list path falls back to filesystem scanning whenever the SQLite backfill is not complete yet.
• In the fallback path, codex-rs/core/src/rollout/list.rs was requiring both session metadata and a persisted user_message event before returning a thread item.
• I reproduced the partial-restore shape locally with a focused codex-core test: one normal thread plus two metadata-only session rollouts yielded only the normal thread on the fallback path. Relaxing that filter to require session metadata only brought all three back.
• Branch-backed patch and regression test: https://github.com/SproutSeeds/codex/tree/scratch/issue-13713-thread-list-fallback

So the narrow claim I can support is: there is a real fallback-listing bug here for stored sessions that exist on disk but have not yet persisted a qualifying user-message event. That seems compatible with "only one of three threads is visible after restart."

If anyone on Windows can confirm whether the missing threads were created or resumed before their first typed prompt was persisted, that would help confirm this is the same slice.

I have the same problem. Files stored on network folder. https://github.com/openai/codex/issues/15052

I found a workaround that fixed missing local sessions in the Codex Windows app for me:

Delete the following files in your .codex folder:

• session_index.jsonl
• state_5.sqlite

Then restart the Codex app.

Notes:

• Your sessions are NOT deleted (stored in .codex/sessions/*.jsonl)
• This only forces a rebuild of the local index/cache

do it this and solve ok on windwows or similar for mac/linux

setx CODEX_HOME 'C:\Users\your_user\.codex'

I am experiencing the same issue on Windows 11.

Feedback ID:
019ec2a5-2b4c-7a72-999c-145bfdd16031

The Codex Desktop sidebar and codex resume --all show only 4 threads, although codex doctor --json --all reports:

• 11 active rollout files
• 11 active database rows
• 1 archived rollout file
• 1 archived database row
• 0 missing rows
• 0 stale rows
• 0 duplicate thread IDs
• 0 scan errors

At least one hidden thread can still be opened successfully with codex resume <SESSION_ID>, but it does not reappear in the Desktop sidebar afterward.

Changing the sidebar to Chronological and checking Archived chats did not solve the issue.