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

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

• #27408
• #27353
• #26624
• #27243
• #26031

Powered by Codex Action

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?

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.