Codex Desktop: chats disappear after update/import; imported threads open blank despite JSONL turns
Summary
After updating Codex Desktop and using the Imported agent setup flow, existing local chats appeared to disappear from the Desktop sidebar. The transcript JSONL files were still present on disk and could be recovered manually, but the Desktop app no longer surfaced them normally. Some imported/external chats also open to a blank-looking chat view from codex://threads/<id> even though the app-server can parse the transcript when turns are explicitly requested.
This presents to the user as data loss, even if the raw transcripts still exist.
Related/similar issues I found before filing:
- #18364
- #17540
- #19345
- #19615
- #19873
- #20419
- #14370
Environment
- Codex CLI/Desktop bundle:
codex-cli 0.128.0-alpha.1 - macOS:
26.4.1 25E253 - Architecture:
arm64 - Codex Desktop source: installed app bundle at
/Applications/Codex.app
What happened
- Updated Codex Desktop.
- Used the app's "Imported agent setup" flow.
- After that, older chats were no longer visible in the Desktop sidebar.
- Restarting Codex Desktop did not restore them.
- Rebuilding
session_index.jsonland project/root state made the CLI able to browse/resume sessions, but Desktop still did not reliably display/open imported chats. - A generated local page with
codex://threads/<id>links could navigate into Codex, but the opened chat view was blank for imported chats.
Evidence
The old transcript files still existed under ~/.codex/sessions/..., so the user data was not fully gone from disk.
However, ~/.codex/state_5.sqlite was corrupt immediately after the issue:
file ~/.codex/state_5.sqlitereported genericdata, not SQLite.- App logs contained errors such as:
failed to initialize sqlite state db: file is not a databasesqlite state db unavailable for thread ...
After moving the corrupt DB aside, Codex rebuilt a valid SQLite DB. The rebuilt DB currently contains:
210total threads200unarchived threads113threads with sourcevscode
The import registry exists and shows external sessions were imported:
~/.codex/external_agent_session_imports.json- Contains
72imported external session records.
Example imported thread:
- Thread id:
019ddfce-b73e-7230-ae24-a70b89c76982 - Transcript path shape:
~/.codex/sessions/2026/05/01/rollout-...-019ddfce-b73e-7230-ae24-a70b89c76982.jsonl thread/readwithoutincludeTurns:truereturned metadata/preview butturns: [].thread/readwithincludeTurns:truereturned the actual user and assistant messages.
Desktop logs around opening imported chats included:
Conversation state not found conversationId=...- followed by
maybe_resume_success ... turnCount=1
Despite that, the Desktop UI appeared blank.
There was also repeated log noise for at least one imported thread with cwd /:
No cwd found for local task conversationId=019ddfce-17b1-7893-a39c-d66ace3561f6
Expected behavior
- App updates and import flows should not make existing chats disappear from the Desktop sidebar.
- If
state_5.sqlitemigration/open fails, Desktop should detect the corruption, preserve the DB, rebuild from JSONL, and show a visible recovery/warning state instead of looking like the user's chats are gone. - Imported external sessions should either render correctly in Desktop or be clearly labeled as imported/archive-only with a built-in viewer/export.
codex://threads/<id>should not navigate to a blank chat when the app-server can parse the transcript.
Actual behavior
- Existing chats appeared deleted from the Desktop UI.
- Imported threads could be indexed and listed, but opening them from Desktop/deep link could produce a blank chat.
- Manual recovery was required to rebuild state and create a separate local viewer for the JSONL transcripts.
Local workaround used
- Backed up and moved aside the corrupt
state_5.sqlite. - Allowed Codex to rebuild a valid SQLite DB from local session files.
- Built a separate local HTML viewer directly from the JSONL transcripts to make the recovered chats readable.
I can provide sanitized logs or additional command output if useful.
8 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Recovery note: chats existed on disk, but Desktop hid them
I was able to recover the missing sidebar chats locally. Sharing the exact pattern in case it helps others debug the same failure mode.
What was happening
The rollout JSONL files were still present under
~/.codex/sessions/..., and the rows still existed in~/.codex/state_5.sqlite, but Codex Desktop did not show them in the sidebar.The decisive clue was that some rows looked like real chats but had sidebar-breaking metadata:
| Field | Bad value I saw | Why it matters |
| --- | --- | --- |
|
archived|0| The row was active, so this alone was not the issue. ||
first_user_message| non-empty | The chat had a real user prompt/history. ||
has_user_event|0| Desktop did not treat the row as a normal visible chat. ||
source|execfor some chat-like rows | These did not behave like interactive sidebar conversations. |After fixing those fields for active chats, the sidebar started showing the recovered chats again.
Safety first
Please back up before changing anything:
I also recommend not unarchiving everything blindly. In my case, I had intentionally archived many old chats, so the repair below only touches active rows.
Diagnose
Then look for active rows that have a first user message but bad visibility metadata:
If this returns real project roots/chats, you may be hitting the same bug.
Repair that worked for me
After that, refresh/restart Codex Desktop. For me, a normal UI refresh was enough after the metadata was repaired.
<details>
<summary>Optional: project/sidebar grouping cleanup</summary>
If chats exist but still appear under the wrong project, also inspect:
thread-workspace-root-hintsproject-orderelectron-saved-workspace-rootsThese live in:
In my recovery, adding explicit
thread_id -> cwdhints for active visible threads helped the sidebar group the recovered chats under the expected project roots.</details>
Why I think this is an import/update bug
The affected rows had real rollout history and a non-empty
first_user_message, but were missing the metadata Desktop appears to use for normal chat visibility. That suggests the data was not truly gone; it was present but no longer shaped like a visible interactive thread after the update/import path.Same symptom on the Windows Desktop build (
OpenAI.Codex_26.429.3425.0_x64__2p2nqsd0c76g0), but the underlying filter appears to be different.After a Codex Desktop update on Windows, ~130 of my chats disappeared from the sidebar even though their rollout JSONLs in
~/.codex/sessions/and rows instate_5.sqlite(threadstable) were intact. The disappeared chats were all older than roughly 30 days.Things that did NOT restore visibility on Windows
Each tried in isolation, with full SQLite backups +
integrity_checkbetween attempts:session_index.jsonlto include all rows fromthreads(Codex Desktop appears to ignore added entries here for sidebar purposes).UPDATE threads SET has_user_event=1 WHERE archived=0 AND first_user_message<>''fix from @vishkrish200's comment. Update applied cleanly (213 rows touched,integrity_check ok) but had zero effect on sidebar visibility.UPDATE threads SET source='vscode' WHERE source='exec'(same comment).thread_dynamic_toolsrows from a visible chat to a hidden one (matching tool counts, namespaces, schemas).threads.updated_atandthreads.updated_at_msto the current epoch.thread-workspace-root-hintsentries in~/.codex/.codex-global-state.json.What did work
os.utime(rollout_path, (atime, now))on the disappeared chat's rollout JSONL. The file's content stays bit-identical (verified by SHA256 before/after); only the filesystem mtime changes. After restarting Codex Desktop, the chat reappears in the correct sidebar folder.Repro
rollout_pathexists on disk and whose file mtime is more than ~30 days old. It will not be in the sidebar regardless ofhas_user_event,archived,source,toolscount, etc.os.utime(rollout_path, (atime, time.time())). Restart Codex Desktop.Cutoff observation
Visible chats had rollout mtime ≤ 22.5 days; hidden ones ≥ 37 days. The filter sits somewhere in that 22–37 day window — likely 30 days hardcoded.
Separate caveat (sidebar-grouping, not visibility)
With both
\\?\W:\XandW:\Xfor the same logical path inelectron-saved-workspace-roots, sidebar matching breaks even for chats that satisfy the recency filter — folders show "No chats" until the duplicate is removed. Keep one form per logical path. Mentioning in case it's related.Versions
OpenAI.Codex_26.429.3425.0_x64__2p2nqsd0c76g0cli_version0.101.0→0.126.0-alpha.8Repro / repair script
Single-file Python 3.8+ script with
diagnose,touch, andrestoresubcommands. Readsstate_5.sqliteread-only; the only write operation isos.utime()on rollout JSONL files. Content is SHA256-verified before and after every touch.Quit Codex Desktop before running
touch. The script:archived=1rows (preserves your archived chats).electron-saved-workspace-roots(avoids worktrees / stray paths).# Codex Task(auto-queued tasks, not user chats).In my run on Windows: 48 files touched, 0 SHA256 mismatches, sidebar populated correctly on next Codex Desktop launch.
For anyone landing here with the variant where the local session files still exist but Desktop no longer surfaces the old chats, I documented an unofficial recovery workflow here:
https://github.com/huajiexiewenfeng/codex-session-recovery
It does not replace an upstream fix. It dry-runs first, checks the local session index, global project/sidebar state, SQLite
threads.cwd, exactcwdmatching, and Windows path mismatches, then backs up before writing and verifies the recovery.It may be useful only for cases where the local session data is still present and the issue is metadata/index/project association rather than truly missing transcript files.
I can add another macOS data point that looks related, with identifying details intentionally omitted.
Symptom
On Codex Desktop for macOS, adding one specific local project root caused every local chat pane to render blank, including chats from unrelated projects. Removing that one project root restored normal behavior for the other projects.
This looked like data loss in the UI, but the underlying local data was still readable from
~/.codex.What made this case stand out
The affected project had a much larger local Codex history footprint than the other projects:
tokens_usedOther project roots with smaller histories could be restored and opened normally.
Things we tried
These did not make the original project root safe to re-add:
PRAGMA quick_checkonstate_5.sqlitewas OK.threads.cwdvalues to a quarantine workspace.process_manager/chat_processes.json.cwdwith SQLitethreads.cwd.chat_processes.json.sessions/archived_sessions.Even after that, adding the original project root still made the Desktop UI blank.
Current workaround
The only stable workaround was:
Hypothesis
Codex Desktop may be deriving project/history membership from more than one local state source, not only
state_5.sqliteorchat_processes.json. Stale workspace references in session metadata, combined with a very large project history, may be enough to break project enumeration or renderer state for all chats.It would help a lot to have an official repair/reindex/quarantine command, and a UI error state instead of a blank pane when one project’s local history is too large or internally inconsistent.
I’m not attaching raw local files because they include private chat content, local paths, business context, and authentication-adjacent metadata.
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:
codex resume --all <thread-id>rehydrated itsession_index.jsonl/state_5.sqlite/.codex-global-state.jsonfixed itlistAllThreadspatch fixed itIn my case, the missing project threads still exist in
~/.codex/sessionsandstate_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.In my macOS case, I did not get all hidden project threads durably restored back into the original Desktop project sidebar.
The stable workaround is still the one I described earlier:
For my case, restarting/reindexing, SQLite integrity checks, moving/quarantining cwd values, archiving affected threads, and removing related live session files did not make the original project root safe to re-add.
So my current result is: no durable full sidebar restoration yet; fresh clone at a new path is the only stable workaround I’ve confirmed.
Adding a macOS datapoint after updating to the latest Desktop build.
Environment:
~/.codexRecovery status on my affected project:
state_5.sqlitestill has 251 active/non-archived rows with the expected project cwd.~/.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.