[VS Code Remote Linux] duplicate same-title history entries, blank thread after reopen, and archived thread corruption

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

• #18931
• #19144
• #18963
• #18639

Powered by Codex Action

I reviewed recent related reports in openai/codex on April 24, 2026 and wanted to summarize where this issue seems to overlap with existing bugs vs where it appears to add new evidence.

Short take

I did not find an older report that clearly matches the full combination seen here:

• duplicate same-title history entries appearing simultaneously
• one affected thread reopening as blank after restart
• the same class of corruption also affecting archived history
• duplicate thread records confirmed in local persisted state (session_index.jsonl and state_5.sqlite)

So I do not think this is just a duplicate of one earlier issue.

Most relevant related issues

1. History/restore failure after restart

• #14812 VS Code extension loses thread history after restart on Linux even though auth session is restored
• Opened March 16, 2026

This is the closest match on the restart/rehydration path.

Strong overlap:

• Linux
• VS Code extension
• auth/session restore appears fine, but thread/history restore is broken
• warnings include:
• Received broadcast but no handler is configured method=thread-stream-state-changed
• Item not found in turn state

Difference:

• #14812 mainly reports missing/restoration failure in the UI after restart
• the present issue adds stronger persistence-layer evidence: duplicate thread rows on disk and archive corruption

2. Blank/stuck when opening prior history

• #18993 Unable to open past conversation history in VS Code extension
• Opened April 22, 2026

Strong overlap:

• clicking historical conversations leads to blank/stuck chat area
• previous chat content fails to load

Difference:

• #18993 is more about inability to open old history
• the present issue adds concrete evidence that at least some of these failures may come from duplicated/corrupted local thread state, not just a frontend navigation bug

3. Thread-state broadcast / handler mismatch

• #13343 [VS Code extension][Windows 11] Streaming UI stalls/no token-by-token updates; repeated thread-stream-state-changed broadcasts with no handler
• Opened March 3, 2026

Strong overlap:

• repeated thread-stream-state-changed no-handler warnings
• user reported the problem started after involving additional Remote-SSH windows

Why it matters here:

• this supports the idea that thread-state broadcast / UI handler mismatch is part of the broader failure family
• in the present issue, those warnings appear alongside restore corruption and duplicate persisted threads

4. Remote/WSL runtime failure with missing thread/rollout mapping

• #11721 Cannot create new local conversation (WSL)
• Opened February 13, 2026

Strong overlap:

• remote environment
• PendingMigrationError: navigator is now a global in nodejs
• thread/rollout mapping failures such as missing rollout path / missing thread conversation linkage

Why it matters here:

• this suggests that PendingMigrationError is not harmless noise in remote scenarios; it may be part of a larger failure chain that can affect thread/session integrity

5. Remote SSH crash with PendingMigrationError

• #16830 VSCodium + RemoteExplorer + Codex via ssh - Codex crash
• Opened April 5, 2026

Strong overlap:

• remote SSH-style environment
• direct PendingMigrationError evidence

Why it matters here:

• reinforces that remote extension-host / migration instability is still an open problem in recent versions

6. Session metadata/title integrity issues

• #15368 Increase cap of sessions in VS Code extension
• Opened March 21, 2026

This one is not the same bug, but it is highly relevant.

Why it matters:

• it documents that local thread/session metadata in the VS Code extension can become incomplete or inconsistent
• specifically, blank titles in state_5.sqlite even when disk/session index still had a usable thread name

Why that matters here:

• the present issue has corrupted titles containing tool/protocol fragments
• together, these reports suggest the extension’s session metadata/index path is fragile under failure/recovery conditions

7. Error/log storm / renderer instability

• #18515 VS Code Codex extension log/error loop precedes renderer crashes
• Opened April 19, 2026

Not the same symptom, but relevant background:

• repeated log storm / extension instability
• renderer crashes shortly afterward

Why it matters here:

• in the present case there were also overload signals such as:
• dropping overload response for connection ConnectionId(0): outbound queue is full
• that makes it plausible that UI/backend desynchronization and dropped state updates can escalate into corrupted restore/index state

Working synthesis

Taken together, these reports suggest a broader issue family in the VS Code extension around thread/session state integrity, especially in remote Linux / WSL / SSH-like environments:

1. Remote extension-host activation/migration can fail (PendingMigrationError).
2. Thread-state broadcasts may continue while UI handlers are missing or not ready.
3. State updates can be dropped under overload (outbound queue is full).
4. Session restore / replay / indexing can then produce inconsistent thread metadata.
5. Downstream symptoms vary by user/environment:

• history not restored after restart
• old conversations open blank or stuck
• titles missing or malformed
• session list incomplete
• in this issue: duplicate persisted threads and archive corruption

Why this issue still seems distinct

The earlier issues establish that:

• restart restore failures are real
• blank history load failures are real
• thread-state broadcast handler mismatches are real
• remote runtime/migration problems are real
• session metadata can already become inconsistent

But this issue appears to be the clearest evidence I found of a more severe end state:

• duplicate thread records persisted locally for the same user intent
• same-title duplicate history entries visible at the same time
• archive history affected too
• corrupted thread titles containing tool/protocol serialization fragments

That combination makes this feel like either:

• a more advanced manifestation of the same restore/state bug family, or
• a previously unreported persistence-layer variant within that family

If helpful, I can upload a sanitized support bundle focused specifically on:

• session_index.jsonl
• state_5.sqlite
• logs_2.sqlite
• affected rollout JSONL files
• relevant remoteexthost.log
• relevant openai.chatgpt/Codex.log

Related issues referenced above:

• #14812
• #18993
• #13343
• #11721
• #16830
• #15368
• #18515

Update: I was able to reproduce the duplicate persisted-thread behavior again from a fresh local Codex state.

Before reconnecting VS Code Remote, I moved the previous state out of the way:

mv ~/.codex ~/.codex.broken-2026-04-24

Then I reopened VS Code, reconnected to the Linux server, and started a new Codex conversation. A fresh ~/.codex directory was created at about 2026-04-24 13:56:18 +0800.

Within that fresh state, ~/.codex/session_index.jsonl already contained duplicate same-title entries:

{"id":"019dbe0f-3dcd-7f43-af63-71b972af13a4","thread_name":"检查 bug 是否仍存在","updated_at":"2026-04-24T05:56:23.192409432Z"}
{"id":"019dbe0f-3dd6-74d3-a988-c091f423b65f","thread_name":"检查 bug 是否仍存在","updated_at":"2026-04-24T05:56:23.193076053Z"}

The same duplicate title is also present in the fresh ~/.codex/state_5.sqlite threads table:

title                n  ids
-------------------  -  ------------------------------------
检查 bug 是否仍存在  2  019dbe0f-3dcd-7f43-af63-71b972af13a4
                        019dbe0f-3dd6-74d3-a988-c091f423b65f

Both ids point to separate non-empty rollout files under the new ~/.codex/sessions/2026/04/24/ directory.

So this is not only legacy corruption from the previous ~/.codex; duplicate persisted thread creation still reproduces after moving the old state away, reconnecting VS Code Remote, and starting a new conversation with a fresh local Codex state.

I'm facing a similar problem. VS Code Remote-SSH to HPC Linux. ChatGPT login is valid: codex login status returns logged in. This is not a pure auth failure. Local Codex app-server/transport enters reproducible overload: logs show thousands of outbound queue is full, dropping overload response, server overloaded, plus thread/resume, thread-read-state, PendingMigrationError; app-server later exits with SIGTERM and extension reports disconnected / Codex process not available. CLI smoke also times out during model refresh: failed to refresh available models: timeout waiting for child process to exit. The strongest trigger appears to be old thread recovery, especially thread, with which also returning overloaded on thread/resume. Removing/renaming active ~/.codex makes the extension usable again, suggesting local state/session hydration/backpressure rather than backend unavailability.

The duplicate thread rows plus blank reopen/archived corruption make this a strong persisted-state case for codex-rescue==0.1.0a4.

If the original state is still preserved, could you run:

pipx install codex-rescue==0.1.0a4
codex-rescue sessions
codex-rescue doctor --latest

The commands are read-only. They won’t rewrite the VS Code/Codex state DB, but they can surface duplicate inventory, malformed rollout records, unfinished correlations, and other durable inconsistencies without touching the originals.

A sanitized findings/count summary is enough. Please don’t post raw rollouts, SQLite DBs, extension logs, prompts, tool output, credentials, repository data, thread IDs, or private paths.