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

Summary

In a VS Code Remote session on Linux, the Codex extension persisted duplicate conversation history entries with the same title, and after restarting VS Code one of the affected conversations reopened as a blank thread. The same class of corruption is also visible in archived history.

This does not appear to be only a UI-list duplication bug. I confirmed duplicate thread records in the local persisted Codex state.

This may be related to open issues around thread restore / no-handler thread broadcasts / PendingMigrationError, but this case appears more severe because duplicate thread records are written to disk and archived history is also affected.

Possibly related:

• #14812
• #13343
• #11721

Environment

• Date observed: April 24, 2026
• IDE: VS Code Remote / server-side extension host
• Platform: Linux server via Remote connection
• Extension id: openai.chatgpt
• Current extension path: /home/ghj/.vscode-server/extensions/openai.chatgpt-26.422.21459-linux-x64
• Previous extension path also observed during the same period: /home/ghj/.vscode-server/extensions/openai.chatgpt-26.417.40842-linux-x64
• Local Codex state dir: /home/ghj/.codex

What happened

I had an existing main conversation in the Codex sidebar/history.

Then the following happened:

1. Two history entries with the same title appeared at the same time.
2. One of them was the main conversation I had been using.
3. After exiting VS Code and reopening it, that main conversation opened as blank.
4. The same general problem is also visible in archived history.

Confirmed persisted-state evidence

Duplicate threads exist in the persisted index and SQLite state

I found duplicate titles with different thread ids in both:

• ~/.codex/session_index.jsonl
• ~/.codex/state_5.sqlite (threads table)

Examples:

• 查看当前文件夹
• 019dbd5d-bc1c-7372-8a89-f080377714b5
• 019dbd5e-3dfe-77a2-9433-641d9db26c37
• 部署 PyTorch 教程项目
• 019dba08-5438-7952-a413-10d82310f4cd
• 019dba09-367d-7750-ab79-0d19bdfafa09
• 019dba09-367d-7750-ab79-0d23cc726822

So this is not just a list-rendering duplication. Duplicate thread records were persisted locally.

Corrupted thread titles

Some thread titles were polluted with tool/protocol fragments, for example strings like:

• '} to=final ...
• }]

This suggests thread-title extraction or replay/reindex logic is consuming malformed serialized content.

Duplicate threads point to distinct rollout files

For the duplicate 查看当前文件夹 entries, the two thread records point to different rollout files:

• /home/ghj/.codex/sessions/2026/04/24/rollout-2026-04-24T10-42-10-019dbd5d-bc1c-7372-8a89-f080377714b5.jsonl
• /home/ghj/.codex/sessions/2026/04/24/rollout-2026-04-24T10-42-43-019dbd5e-3dfe-77a2-9433-641d9db26c37.jsonl

Both files contain real session streams, so the same user intent appears to have been materialized into more than one conversation record.

Archived history is also affected

Archived duplicate rollout files exist for the same user prompt under ~/.codex/archived_sessions, including multiple archived threads with the same title.

Relevant logs and timing

During the same period, I found the following signals:

1. Extension activation / migration failures

In VS Code remote extension host logs on April 24, 2026, I repeatedly saw:

• PendingMigrationError: navigator is now a global in nodejs

This affected both:

• openai.chatgpt-26.417.40842-linux-x64
• openai.chatgpt-26.422.21459-linux-x64

2. Transport overload

In both Codex local logs and the extension logs, I repeatedly saw:

• dropping overload response for connection ConnectionId(0): outbound queue is full

3. Missing IPC handlers for thread state broadcasts

I repeatedly saw warnings like:

• Received broadcast but no handler is configured method=thread-stream-state-changed
• Received broadcast but no handler is configured method=thread-read-state-changed

4. Local backup created during the affected period

A backup directory also appeared locally during the same period:

• ~/.codex.backup.20260424-105549

That timestamp lines up with the window where the repeated thread-state warnings and restore anomalies were happening.

Working hypothesis

This looks like more than a simple frontend history-list issue.

A plausible failure chain is:

1. extension activation/migration fails intermittently
2. extension host / Codex app-server state gets out of sync
3. thread-state broadcasts arrive while handlers are missing
4. transport overload starts dropping responses
5. session restore/replay or recovery persists duplicate thread records
6. title extraction or reindexing consumes malformed event content
7. on reopen, one affected thread cannot hydrate correctly and appears blank

Expected behavior

• A conversation should have exactly one persisted thread record unless the user explicitly creates a new conversation.
• Reopening VS Code should not produce duplicate same-title history entries.
• Existing threads should reopen with their content instead of rendering as blank.
• Archived history should not accumulate duplicate/corrupted thread records.
• Thread titles should never contain protocol/tool serialization fragments.

Additional notes

I preserved the local evidence and did not clear ~/.codex after the failure.

If useful, I can provide a sanitized support bundle containing:

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