Cannot create new local conversation (WSL)

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

• #11693

Powered by Codex Action

Same type of error for me.

What issue are you seeing?

When using the Codex extension in Visual Studio Code, attempting to create a new thread or resume an existing one fails with a red pop up "Failed to resume task" or "Error creating task". The logs shows an internal error indicating a missing rollout for a thread. Even in a fresh workspace, and on different OS, this happens consistently.

The error in the VS Code extension logs looks like:

Request failed conversationId=<…> durationMs=… error={"code":-32600,"message":"no rollout found for thread id <…>"}
Failed to resume conversation conversationId=<…> error={"code":-32600,"message":"no rollout found for thread id <…>"}

What version of the extension are you using?

• Codex VS Code extension version: 0.4.74. The same happens with 0.4.73
• Downgrading to version 0.4.71 fix the issue.

What subscription do you have?

• Pro

What IDE are you using?

• Visual Studio Code
• Platforms tested: Linux, Windows

Steps to reproduce

1. Install the Codex extension (current version).
2. Open VS Code in a new/empty workspace.
3. Initiate a new Codex thread (in the main windows, not the side panel) and attempt to start a new conversation or task, or resume an old one.

What is the expected behavior?

Starting a new conversation/task should proceed as intendend and allow interaction without errors.

Additional context

The problem happens even with a completely empty workspace and after re-logging in. I also try reinstalling the Codex extension, and renaming the .codex folder. There are no network errors prior to the internal error, indicating the issue occurs in the session state / rollout management layer.

Logs contain consistent messages about rollouts missing for newly created thread IDs, suggesting an internal state binding failure.

Thanks @donQuiM , I downgraded to 0.4.71 and the issue resolves.

Additional diagnostic findings (WSL2 + Remote SSH)

Spent several hours today systematically diagnosing this on a WSL2 setup. Adding findings that narrow the root cause significantly.

Environment

• OS: WSL2 (Ubuntu) on Windows, connecting via Remote SSH
• Extension versions tested: 0.4.71, 0.4.76, 0.5.76 (pre-release) — all exhibit the same tab bug
• CLI versions tested: 0.98.0 (bundled with 0.4.71), 0.104.0-alpha.1 (bundled with 0.4.76)

Key finding: Sidebar works, editor tab does not

The sidebar panel creates and runs conversations correctly. The editor tab fails every time with "no rollout found for thread id". This is true even with:

• Completely empty ~/.codex/sessions/ directory
• Fresh workspace with no prior state
• Latest extension + CLI versions with the 0.102.0 rollout fixes

The tab generates a brand-new conversation ID on every open, then immediately calls thread/resume on it. The CLI correctly responds "no rollout found" because the conversation was never created server-side — the tab's code path calls resume where it should be calling create.

Log evidence

Extension startup → tab opens → new ID generated → resume attempted → fails:

[info] Conversation created conversationId=019c7c6c-eb4c-7fc0-ac63-7b8427f8b386
[error] [CodexWebviewProvider] Error fetching conversation summary error={"code":-32600,"message":"no rollout found for conversation id 019c7c6c-eb4c-7fc0-ac63-7b8427f8b386"}
[error] Request failed conversationId=019c7c6c-eb4c-7fc0-ac63-7b8427f8b386 method=thread/resume error={"code":-32600,"message":"no rollout found for thread id 019c7c6c-eb4c-7fc0-ac63-7b8427f8b386"}
[error] Failed to resume conversation conversationId=019c7c6c-eb4c-7fc0-ac63-7b8427f8b386

Note: no state db record_discrepancy warnings — the state DB is clean. The bug is purely in the tab webview's conversation initialization path.

What we ruled out

| Attempted fix | Result |
|---|---|
| Clear all ~/.codex/sessions/ | Tab still fails |
| Clear shell_snapshots + tmp | Tab still fails |
| Remove ghost IDs from VSCode workspace state DBs (agentSessions.model.cache, memento/workbench.parts.editor) | Tab generates new ghost on next open |
| Downgrade to 0.4.71 | Tab still fails (contradicts earlier reports — may be environment-specific) |
| Upgrade to 0.4.76 (CLI 0.104.0-alpha.1 with rollout fixes) | Tab still fails |
| New workspace | Tab still fails |
| Full computer restart | Tab still fails |

Secondary issue: cascading session corruption

When the tab repeatedly fails, it creates orphaned conversation IDs in the VSCode workspace state DB (state.vscdb on the Windows side at AppData/Roaming/Code/User/workspaceStorage/*/state.vscdb, key agentSessions.model.cache). Over time these accumulate and eventually corrupt the sidebar's functionality too — the CLI starts logging state db record_discrepancy: find_thread_path_by_id_str_in_subdir, falling_back on every operation, which breaks new session creation even in the sidebar.

Workaround for the cascading corruption: Clear ~/.codex/sessions/, ~/.codex/shell_snapshots/, and ~/.codex/tmp/, then use the sidebar only.

Summary

The bug is in the extension's editor tab webview code path — it calls thread/resume on a newly-generated conversation ID instead of properly creating the thread first. The sidebar uses a different (working) code path. The CLI is not at fault.

Hey! I ran into a similar pattern in our bug knowledge base and thought this might help.

What's happening: Node.js v21+ added navigator as a global (via globalThis.navigator). The Codex extension (or a dependency like an OpenAI SDK) uses typeof navigator !== 'undefined' as a browser-detection heuristic. This now incorrectly resolves to true in Node.js/WSL, causing browser-only code paths (e.g., navigator.userAgent, navigator.locks, fetch with browser headers) to execute in the Node.js extension host, which crashes.

What worked for us:

Replace browser-detection checks from typeof navigator !== 'undefined' to typeof window !== 'undefined' (window is NOT a Node.js global). Alternatively, check navigator.userAgent existence specifically or use globalThis.process?.versions?.node to positively identify Node.js. For the WSL user: as a workaround, launch VS Code with --no-experimental-global-navigator flag or set NODE_OPTIONS=--no-experimental-global-navigator before launching, which disables the Node.js navigator global.

# User workaround (in WSL shell before launching VS Code):
export NODE_OPTIONS="--no-experimental-global-navigator"
code .

# Or in VS Code settings.json:
# "terminal.integrated.env.linux": { "NODE_OPTIONS": "--no-experimental-global-navigator" }

# Upstream fix (in the extension/SDK code):
# Before:
-if (typeof navigator !== 'undefined') {
-  // assume browser
-}
# After:
+if (typeof window !== 'undefined' && typeof window.document !== 'undefined') {
+  // actually a browser
+}

Hope this helps! Let me know if it doesn't match your case — happy to dig deeper. 🦞

_Disclosure: This analysis is from Confucius Debug, an AI-powered community KB for agent bugs. Please verify before applying._

---
_{🦞 Confucius Debug — community knowledge base for AI agent bugs. Free to search via MCP.}

The state db missing rollout path / no rollout found errors despite a rollout existing on disk make this a direct session inventory/parity case for codex-rescue==0.1.0a4.

If you still have the preserved WSL state, 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 repair the VS Code extension/runtime, but they can independently report whether rollout discovery, filenames, duplicate/missing inventory, and persisted session structure are consistent.

Please share only sanitized status/findings/aggregate counts. Don’t post raw rollout files, SQLite DBs, extension logs, prompts, tool output, credentials, repository data, thread IDs, or private paths.