🩹🩹 Codex Windows app: project chats disappear after update and after first response #27453

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

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

   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 Jun 10, 2026
2. github-actions commented on Jun 10, 2026

   

   github-actionsbot

   on Jun 10, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Conversations disappear from sidebar after Windows reboot, but Search still finds and opens them #27408
   • Project chat history disappeared after latest Codex app update #27353
   • # Bug Report: Windows Codex Desktop Shows Empty Project Chats While Mobile Shows History #26624
   • Windows: sidebar shows 'No chats' in project folders because cloud sync rewrites threads.cwd with \\?\ extended-length prefix #27243
   • Codex app project chat history disappears after reopening app #26031

   Powered by Codex Action
3. EngineeringElation commented on Jun 27, 2026

   

   EngineeringElation

   on Jun 27, 2026

   More actions

   Adding a fresh Windows repro after updating to a newer Codex Desktop build. This is sanitized for public GitHub; exact thread id and exact local path are omitted here, but I have them available for private /feedback.

   Environment:

   • Windows Codex Desktop AppX: OpenAI.Codex_26.623.5175.0_x64__2p2nqsd0c76g0
   • Previous AppX observed before update/reopen: OpenAI.Codex_26.623.3763.0_x64__2p2nqsd0c76g0
   • Browser/Chrome plugin bundle after update: 26.623.41415
   • CLI version recorded in affected DB row: 0.142.3
   • Model recorded in affected DB row: gpt-5.5, xhigh
   • Affected project path redacted: C:\Users\<user>\Code\Unreal\<project>

   Fresh repro:

   1. Had an unread/recently completed local project chat in the affected project.
   2. Closed Codex.
   3. Let Codex update.
   4. Reopened Codex.
   5. The repo work remained, but the chat disappeared from sidebar/project list and search. It is not archived and is not visible on mobile.

   Local evidence:

   • state_5.sqlite row exists for the affected thread.
   • Row is thread_source='user', source='vscode', archived=0, archived_at=NULL.
   • The row's cwd uses the Windows verbatim-prefix form: \\?\C:\Users\<user>\Code\Unreal\<project>.
   • The rollout JSONL file exists under C:\Users\<user>\.codex\sessions\... and was about 609 KB.
   • preview='' and first_user_message='' in the affected DB row.

   Direct access works:

   • codex_app.read_thread by id succeeds.
   • It returns the title, cwd, and completed turn content.

   Normal discovery fails:

   • codex_app.list_threads top 50 omits the affected thread even though it is one of the newest DB rows.
   • codex_app.list_threads query for the exact title returns [].
   • codex_app.list_threads query for a title keyword returns [].
   • Querying the project name returns other older project threads, but not this one or the related blank-preview thread series.

   Local DB pattern on this machine:

   • User threads in DB: 131
   • User threads with blank preview: 22
   • User threads whose cwd starts with \\?\: 131
   • Recent hidden project threads are active/unarchived, present in DB, have rollout files, and have blank previews.

   Relevant log signals around the affected thread:

   • thread/read resumed the rollout successfully.
   • thread/name/updated set the title.
   • incremental request failed, items didn't match.
   • Repeated unhandled responses event: response.function_call_arguments.delta/done.

   This looks related to #25463, #27243, and the closed duplicate #22777. My current hypothesis is that two issues overlap on Windows:

   1. Project/sidebar grouping is vulnerable to \\?\ cwd normalization mismatch.
   2. thread/list / search can drop valid sessions when preview and first_user_message are blank or preview reconstruction fails. Direct read_thread still works, so the thread should probably appear as a title-only row instead of disappearing.

   Expected behavior: valid, unarchived local user threads with existing rollout files should remain visible in sidebar/list/search even if preview derivation fails.

   Is there a supported local repair/reindex command for this state, and is thread/list being changed to tolerate blank preview / preview reconstruction failures?
4. EngineeringElation commented on Jun 27, 2026

   

   EngineeringElation

   on Jun 27, 2026

   More actions

   Follow-up after more local diagnosis on the same Windows machine. This is still sanitized; exact local thread ids and exact local username are omitted publicly.

   I found two separate failure modes that overlap:

   1. Blank previews make threads invisible to the normal visible-thread path

   The local threads table has partial indexes that only include rows with non-empty preview text:

   CREATE INDEX idx_threads_visible_created_at_ms
       ON threads(archived, created_at_ms DESC)
       WHERE preview <> '';
   
   CREATE INDEX idx_threads_visible_recency_at_ms
       ON threads(archived, recency_at_ms DESC, id DESC)
       WHERE preview <> '';
   
   CREATE INDEX idx_threads_visible_updated_at_ms
       ON threads(archived, updated_at_ms DESC)
       WHERE preview <> '';

   The newest missing chats had:

   thread_source='user'
   source='vscode'
   archived=0
   preview=''
   first_user_message=''
   rollout JSONL exists
   read_thread by id succeeds
   

   So those rows were valid and readable, but excluded from the visible-index condition. They were mostly attachment-only / pasted-text-request chats where the title was generated later.

   A local test repair that set preview = title for active user rows with blank previews changed 23 rows. After that, the DB had:

   active_user_blank_preview = 0
   

   That appears to address one class of missing thread metadata, though the running app process still had stale list/search state until refresh/restart.

   2. Project hierarchy still breaks because live app state rewrites cwd back to \\?\...

   The same machine also has the Windows path-normalization issue from #27243. The saved project root is normal:

   C:\Users\<user>\Code\Unreal\<project>
   

   But affected threads.cwd rows are rewritten to:

   \\?\C:\Users\<user>\Code\Unreal\<project>
   

   I stripped the \\?\ prefix from threads.cwd as a local SQLite test. It initially made the DB match the saved project root, but while Codex was still running the app/sync/reconciliation path rewrote many rows back to the prefixed form almost immediately.

   Current counts after that live rewrite:

   active_user_blank_preview = 0
   active_user_prefixed_cwd = 109
   active_all_prefixed_cwd = 123
   
   for the affected project:
   endless_active_user_plain = 7
   endless_active_user_prefixed = 61
   endless_active_all_plain = 184
   endless_active_all_prefixed = 66
   

   A read-only finder for the affected project currently reports:

   candidate_count = 68
   attachment_only_or_repaired = 24
   prefixed_cwd = 61
   

   Pin/unpin behavior

   Pinning one hidden thread made it visible/recoverable. After unpinning it, it disappeared again. That suggests pinned threads are shown through a different surface that bypasses or supplements the broken project/list discovery path. Once unpinned, the thread falls back into the broken combination of cwd mismatch / stale discovery.

   Why this seems actionable

   I think there are two fixes needed:

   1. thread/list / search / sidebar should not drop valid active rows when preview is blank. It should render a title-only fallback or derive preview from the first readable user item, even for attachment-only prompts.
   2. Windows cwd normalization needs to happen consistently before DB writes, project-sidebar grouping, cloud/local reconciliation, and search/list filtering. A local DB repair is not durable while Codex is running because the prefixed cwd gets reintroduced.

   A supported local repair/reindex command would also help users recover existing state without manual SQLite edits.
5. linear

   added

   Broken flow

   Papercuts 2026

   Truffle Pig feedback

   Papercuts: Source - Truffle Pig

   Papercuts: Type - Broken flow

   and removed

   Truffle Pig feedback

   Broken flow

   on Jul 29, 2026
6. linear

   changed the title [-]Codex Windows app: project chats disappear after update and after first response[/-] [+][L] Codex Windows app: project chats disappear after update and after first response[/+] on Jul 31, 2026
7. linear

   changed the title [-][L] Codex Windows app: project chats disappear after update and after first response[/-] [+][M] Codex Windows app: project chats disappear after update and after first response[/+] on Jul 31, 2026
8. linear

   added

   Windows

   on Jul 31, 2026
9. linear

   changed the title [-][M] Codex Windows app: project chats disappear after update and after first response[/-] [+]🩹🩹 Codex Windows app: project chats disappear after update and after first response[/+] on Aug 3, 2026