VS Code extension loses thread history after restart on Linux even though auth session is restored

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

• #14657
• #13583
• #13343
• #14179

Powered by Codex Action

I reviewed the suggested duplicates and I don’t think this issue is a direct duplicate.

Closest related issue:

• #14179: conversation/local rollout loading failure (Conversation not found / no rollout found)

Other related issues with overlapping extension warnings:

• #13583
• #13343
• #14657

Why I’m keeping this open:

• my issue is specifically about restart-time restoration of visible thread history on Linux
• auth session is restored successfully
• rollout/session files still exist on disk
• the UI still loses/restores thread state incorrectly after restart

So this seems related to the same extension state/IPC family, but not the same end-user failure mode.

I can confirm a related VS Code extension / Linux metadata-hydration bug.

Concrete example from my machine:

• thread id: 019ca226-b30c-7181-bdf0-62b891464a25
• ~/.codex/session_index.jsonl still had thread_name = "Worker"
• the rollout file still existed on disk
• but ~/.codex/state_5.sqlite had title = '' and first_user_message = '' for the same thread id

Result:

• Codex CLI could still find the session as Worker
• the VS Code extension could not reliably surface it by name

After manually updating the row in state_5.sqlite so that threads.title = 'Worker', the thread became visible in the extension immediately after reload.

This suggests the extension is trusting recent-thread metadata/state too much and does not repair blank titles from disk-backed sources.

Relevant code paths from the current extension sources / sourcemaps:

• src/app-server/app-server-manager.ts
• upsertRecentConversationState() around lines 1389-1415
• new conversation state gets title: persistedTitle around line 1472
• src/local-conversation/get-local-conversation-title.ts
• fallback uses only conversation.title, first turn input text, and parent subagent prompt
• there is no fallback to session_index.jsonl, rollout JSONL, or recovery history

So this is not only “history lost after restart”; it can also be “history present on disk but undiscoverable because blank titles are never repaired”.

Windows 11 repro here with the current VS Code extension, and the failure pattern matches this issue.

Environment:

• IDE extension: openai.chatgpt 26.325.31654
• VS Code: 1.113.0
• Platform: Windows 11
• Workspace: local folder workspace
• Codex data root: %USERPROFILE%\\.codex

Observed behavior:

• Local Codex conversations disappear from the VS Code UI after closing/reopening VS Code.
• The underlying thread/session data is still present locally.
• Recovering/exporting the conversations from .codex works, but the extension does not restore them correctly in the UI.

Confirmed local state:

• Threads still exist in %USERPROFILE%\\.codex\\state_5.sqlite (threads table).
• Rollout files still exist under %USERPROFILE%\\.codex\\sessions\\2026\\03\\31\\.
• Recovered/exported transcripts exist for the missing conversations, so this is not raw data loss.

Key failing threads on this machine:

• 019d44bd-7f5c-7e21-8ed0-f681a1e03b2c
• 019d44c9-2f2b-7270-83fc-631cd4e57795

Extension log symptoms after restart:

• repeated Item not found in turn state
• repeated Received broadcast but no handler is configured method=thread-stream-state-changed
• I also saw earlier Conversation state not found during investigation

Important detail from local repair attempts:

• I backed up the active workspace DB and removed stale openai-codex://route/local/... entries from the active VS Code workspace state.vscdb.
• The cleanup did run successfully.
• After restarting VS Code, agentSessions.state.cache stayed clean, but agentSessions.model.cache was repopulated by the extension.
• The restore failure persisted immediately after restart, with fresh Item not found in turn state errors.

That suggests the durable Codex store is intact, but the VS Code extension’s restore / turn-state hydration path is rebuilding broken session pointers or failing to hydrate from the persisted rollout/thread data.

I also saw unrelated extension-side errors during startup such as:

• local-environments is not supported in the extension
• MCP auth failures for some connectors
• connector logo fetch overloads

Those may be noise, but the thread restore failure remains reproducible even after cache cleanup.

Practical conclusion from this Windows repro:

• deleting or cleaning workspace cache is not a durable fix
• the extension can recreate the broken restore state on next launch
• the bug appears to be in extension-side session/turn-state restore, not missing .codex files

If useful, I can provide a sanitized list of the exact workspace DB keys and the before/after cache counts from the successful cleanup run.

do it this and solve ok on windwows or similar for mac/linux

setx CODEX_HOME 'C:\Users\your_user\.codex'

I’m seeing what looks like the same underlying issue, but in VS Code + WSL.

In my case, this is not full history loss. It is more like partial / thread-specific restore failure:

• the thread title still appears in the IDE history
• the thread still exists in ~/.codex/session_index.jsonl
• the transcript file still exists in ~/.codex/sessions/...
• but some threads do not rehydrate when reopened after restarting VS Code

Important detail:

• some threads reopen correctly
• others show the title but not the content
• so this looks intermittent or thread-specific, not total session loss

This makes me think the root issue is still thread/session restore or sidebar/UI hydration after restart.

Feedback session ID:
5163bfa8-60d4-4787-8da4-e37f535414a3

Additional finding:

I found a much more specific repro path.

When I open VS Code and land on the initial CODEX view, I see the recent tasks list. If I click tasks from that initial recent-tasks view, the thread does not open correctly.

However, if I open the same task through Task history, the exact same thread opens correctly and the full content loads.

I tested this with multiple tasks:

• tasks fail to open from the initial CODEX recent list
• the same tasks open correctly from Task history

This suggests the problem may not be transcript loss or broken local storage. It looks more like a bug in the initial recent-tasks entry point / navigation / task resolution, while Task history uses a different and working restore path.

Additional note:
For one failing thread, the UI showed the context window around 75% full (~193k / 258k tokens). I am not sure this is causal, but mentioning it in case it is relevant to restore/hydration behavior.