Codex Desktop appends new turns to wrong existing thread after update/restart; sidebar/catalog stale

[mkhaytman87]

Codex Desktop appends new turns to wrong existing thread after update/restart; sidebar/catalog stale

Summary

After updating and restarting Codex Desktop, multiple local chat/session records became inconsistent:

1. A recently active thread appeared in the sidebar as if it had not been updated, even though its raw rollout JSONL continued well past the sidebar/index timestamp.
2. New work for one project was appended to an unrelated old pinned thread from another project.
3. The local thread catalog database appeared to contain only the current investigation thread as recent, while many raw rollout transcripts still existed under ~/.codex/sessions.

This is more severe than a hidden/sidebar-only issue because it caused cross-thread context contamination. A thread for Project A now contains turns and task completions for Project B.

I am intentionally omitting client names, domains, proprietary content, exact local project paths, and task-specific message content from this public issue.

Environment

• Platform: macOS
• Codex Desktop app: 26.623.31921
• App bundle id: com.openai.codex
• Codex CLI: 0.142.2
• Originator in affected raw session metadata: Codex Desktop
• Source in affected raw session metadata: vscode
• Workspace root: local macOS home/workspace

What Happened

Case 1: sidebar/index timestamp stale while raw transcript is complete

One thread, created on 2026-06-25, showed in the app/sidebar as last updated around 2026-06-25T19:10Z.

The raw rollout JSONL for that same thread contains later turns through approximately 2026-06-25T20:27Z, including final task-complete output.

So the raw transcript appears preserved, but the app/index/sidebar did not reflect the true last update.

Case 2: new project work appended to an unrelated old pinned thread

An older pinned thread, created on 2026-04-30 for Project A, received new turns on 2026-06-26 for Project B.

The contamination is visible in the raw rollout JSONL:

• The raw file starts with the old thread metadata and title/context for Project A.
• Later task_complete entries from 2026-06-26 clearly belong to Project B.
• The app/sidebar still associates that raw transcript with the old Project A thread, which means opening/continuing that thread risks mixing unrelated client/project context.

This is not merely a search/sidebar visibility issue. The actual persisted transcript has turns from the wrong project appended into the wrong thread.

Case 3: local catalog appears incomplete after restart

After the restart, querying the local Codex app catalog database showed only the current investigation thread as recent, even though raw rollout JSONL transcripts for many active/recent threads still existed under ~/.codex/sessions.

Expected Behavior

• Continuing or resuming a thread should append turns only to that thread's own transcript.
• Sidebar/search/thread catalog should reflect the true last timestamp from the raw transcript or whatever canonical store owns local threads.
• An update/restart should not cause an unrelated pinned thread to receive new turns from another project.
• If a migration/index rebuild fails, Codex should preserve raw transcripts and avoid silently mixing thread identities.

Actual Behavior

• A sidebar/index timestamp was stale by more than an hour relative to the raw transcript.
• New Project B turns were appended to an old Project A raw transcript.
• The app catalog no longer looked like a reliable inventory of existing raw sessions.
• The user-facing result was apparent missing chat history plus cross-project context contamination.

Impact

High severity for users working across multiple clients or projects:

• Private/proprietary context can be mixed across unrelated threads.
• Continuing an old thread can pull in unrelated project context.
• Recovery requires manually inspecting raw JSONL files and separating turns by project.
• Users may think chat history is lost when raw data exists but the app catalog/sidebar is stale or misleading.

Sanitized Local Evidence Available

I have preserved local notes with:

• affected thread IDs
• raw rollout file names
• first/last timestamps
• line numbers for relevant task_complete entries
• app/CLI versions
• the stale sidebar/index timestamp observed

I am not attaching those paths or task contents publicly because they include private project/client context. I can provide a sanitized diagnostic bundle or specific metadata privately if there is a secure channel.

Related Issues

This appears related to, but more severe than:

• Codex update unexpectedly archives or hides recent local threads #30163 - Codex update unexpectedly archives or hides recent local threads
• Codex Desktop: phone-created thread opens from Search but is missing from sidebar #30123 - thread opens from Search but is missing from sidebar
• State runtime migration failure causes existing conversation to appear truncated after restart (26.616.81150) Feedback Id: 019ebd3f-d74a-7f13-8357-76aad072ee5f #30042 - state runtime migration failure causes existing conversation to appear truncated after restart

The distinguishing behavior here is that turns for one project were persisted into an unrelated old thread transcript.

[github-actions]

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

• Codex update unexpectedly archives or hides recent local threads #30163
• State runtime migration failure causes existing conversation to appear truncated after restart (26.616.81150) Feedback Id: 019ebd3f-d74a-7f13-8357-76aad072ee5f #30042
• thread/read can report stale updatedAt after replacing SQLite metadata with rollout summary #28870
• Threads disappear from sidebar after updating — migration version-38 checksum mismatch caused by PR #28655 #28689
• Codex project stuck in sidebar: no Remove action, new tasks route into stale project #29438

Powered by Codex Action

[mkhaytman87]

Thanks. I reviewed the suggested duplicates. They appear related, especially #30163, #30042, and #28870, but I don't think this is an exact duplicate.

The distinguishing behavior here is not only hidden/stale sidebar metadata. New turns for one project were persisted into an unrelated older pinned thread's raw rollout JSONL, creating cross-thread/project context contamination. The raw transcript itself now contains turns from the wrong project, not merely an incorrect sidebar timestamp or archived/hidden thread state.

Happy to provide sanitized metadata privately if useful.