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

[diogopereira1990]

What version of the IDE extension are you using?

26.5311.21342

What subscription do you have?

Github Copilot +

Which IDE are you using?

VS Code

What platform is your computer?

Ubuntu 24.04.4 LTS

What issue are you seeing?

After closing and reopening VS Code on Ubuntu, the Codex VS Code extension appears to lose previous conversations/thread history in the UI.

This initially looks like an authentication/session loss, but the logs suggest auth is actually being restored correctly. The visible failure seems to be in thread/session restore or UI hydration after restart.

Relevant findings:

• editSessions.log shows the same authentication session being restored successfully
• rollout/session files still exist under ~/.codex/sessions
• Codex.log shows thread-state related errors such as:
  • No promise for request ID
  • Received broadcast but no handler is configured method=thread-stream-state-changed
  • Item not found in turn state

I also previously saw:

• state db backfill not complete at /home/.../.codex (status: pending)

After rebuilding the local Codex SQLite state files, that backfill warning disappeared, but the thread/history restore issue still remains.

What steps can reproduce the bug?

1. Open VS Code with the Codex extension installed and signed in.
2. Use Codex normally and create one or more conversations.
3. Fully exit VS Code.
4. Reopen VS Code.
5. Open the Codex sidebar/panel and wait for initialization.

For me, previous conversations are no longer restored in the UI after restart.

What is the expected behavior?

Codex should restore the existing signed-in session and preserve previously visible conversation/thread history after restarting VS Code.

The extension should reopen with prior threads still available instead of appearing as if history or session state was lost.

Additional information

Environment:

• OS: Ubuntu 24.04.4 LTS
• Desktop: GNOME
• VS Code: manual install, not Snap
• Extension: openai.chatgpt
• Extension version: 26.5311.21342

Important log evidence:

• editSessions.log:

  Searching for existing authentication session with ID 2918bc5fd4425f38
  Found existing authentication session with ID 2918bc5fd4425f38
  
  

Codex.log after restart contains:
No promise for request ID
Received broadcast but no handler is configured method=thread-stream-state-changed
Item not found in turn state

Additional possibly related message:

Error fetching errorMessage="local-environments is not supported in the extension"
url=vscode://codex/local-environments

What I already tried:

Restarting VS Code
Waiting after restart
Reinstalling the extension
Reinstalling VS Code
Verifying the Linux keyring/libsecret setup
Backing up and rebuilding ~/.codex/state_5.sqlite* and ~/.codex/logs_1.sqlite*
Result:

auth still restores
session rollout files still exist
backfill warning went away after rebuild
thread/history restore issue still remains

Codex.log
CODEX_VSCODE_AUTH_TROUBLESHOOTING.md
CODEX_VSCODE_BUG_REPORT.md
editSessions.log

[github-actions]

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

• [extension][macOS] activation emits unsupported vscode:// route errors, stale feature warnings, and missing system-skill lookups #14657
• VS Code extension 0.4.79: repeated thread-stream-state-changed warnings, missing tool-step streaming #13583
• [VS Code extension][Windows 11] Streaming UI stalls/no token-by-token updates; repeated thread-stream-state-changed broadcasts with no handler #13343
• VS Code extension: existing chats and Cloud work, but creating a new Local conversation fails with “Conversation not found” / “no rollout found” #14179

Powered by Codex Action

[diogopereira1990]

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

Closest related issue:

• VS Code extension: existing chats and Cloud work, but creating a new Local conversation fails with “Conversation not found” / “no rollout found” #14179: conversation/local rollout loading failure (Conversation not found / no rollout found)

Other related issues with overlapping extension warnings:

• VS Code extension 0.4.79: repeated thread-stream-state-changed warnings, missing tool-step streaming #13583
• [VS Code extension][Windows 11] Streaming UI stalls/no token-by-token updates; repeated thread-stream-state-changed broadcasts with no handler #13343
• [extension][macOS] activation emits unsupported vscode:// route errors, stale feature warnings, and missing system-skill lookups #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.

[iqdoctor]

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”.

[jonathankleinberg]

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.

[marciocamello]

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

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