Skip to content

Cannot create new local conversation (WSL) #11721

Open
Open
Cannot create new local conversation (WSL)#11721
Labels
bugSomething isn't workingextensionIssues related to the VS Code extensionwindows-osIssues related to Codex on Windows systems

Description

@BaggyG-AU
BaggyG-AU
opened on Feb 13, 2026

What version of the IDE extension are you using?

v0.5.74 (Pre-Release)

What subscription do you have?

Plus

Which IDE are you using?

VS Code 1.109.3

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Codex VS Code Extension: "Start New Agent" fails in WSL (both 0.5.74 and 0.4.74)

Summary

In VS Code Remote (WSL), starting a new Codex agent consistently fails.
I tested both OpenAI extension versions 0.5.74 (pre-release) and 0.4.74 (stable).
Both versions show the same runtime and thread-state failures.

This seemed to coincide with fact that I had two VS Code projects open - one WSL and one Windows. This may or may not be related.

Date / Time

Initially observed on **February 12, 2026

Environment

  • VS Code Server (Remote WSL)
  • Extension under test: openai.chatgpt
  • Tested versions:
    • 0.5.74 (openai.chatgpt-0.5.74-linux-x64)
    • 0.4.74 (openai.chatgpt-0.4.74-linux-x64)
  • Workspace: /home/micah/projects/HA_Visual_Dashboard_Maker

Actual

  • Extension host throws:
    • PendingMigrationError: navigator is now a global in nodejs
  • Codex logs show:
    • state db missing rollout path for thread ...
    • no rollout found for conversation id ...
    • no rollout found for thread id ...
    • thread/resume request failures with code=-32600

Key evidence

0.5.74

  • ~/.vscode-server/data/logs/20260213T222845/exthost2/remoteexthost.log
  • ~/.vscode-server/data/logs/20260213T222845/exthost2/openai.chatgpt/Codex.log

0.4.74 A/B retest

  • ~/.vscode-server/data/logs/20260213T222845/exthost3/remoteexthost.log
  • ~/.vscode-server/data/logs/20260213T222845/exthost3/openai.chatgpt/Codex.log

A/B result

Downgrading from 0.5.74 to 0.4.74 did not change behavior.
Both versions fail with the same signatures, suggesting an upstream extension/runtime issue rather than a single-version regression.

Extra context

A fresh rollout file exists on disk (example):

  • ~/.codex/sessions/2026/02/13/rollout-2026-02-13T22-29-07-019c56c3-06fc-7db3-a928-9c3607e17129.jsonl

But extension logs still report missing rollout path / missing rollout for thread IDs.

Remediation Steps Already Attempted (February 13, 2026)

I attempted the following remediation steps before filing this report:

1. Initial log review

I reviewed the VS Code Remote (WSL) logs under ~/.vscode-server/data/logs and repeatedly observed:

  • PendingMigrationError: navigator is now a global in nodejs
  • state db missing rollout path for thread ...
  • no rollout found for conversation/thread id ...
  • thread/resume failures with code=-32600

2. Full local reset

I ran a full reset to clear potentially corrupted local state while preserving auth/config:

  • Moved older extension bits out of the active extensions path.
  • Reset workspace storage for workspace ID b6cc891f0c8b9078d9d5396cd8460ca5.
  • Reset local Codex state:
    • ~/.codex/sessions
    • ~/.codex/shell_snapshots

Result: the stale-session behavior changed, but the core failures persisted.

3. Extension scan cleanup

I moved backup folders out of ~/.vscode-server/extensions so VS Code would stop trying to scan non-extension directories as extensions.

Result: extension scan noise was reduced, but the core Codex failure persisted.

4. Reinstall / version-state verification

I verified that pre-release openai.chatgpt-0.5.74 was installed and active in WSL extension host state.

Result: issue remained reproducible on 0.5.74.

5. Controlled A/B version test

I performed a controlled downgrade from 0.5.74 to 0.4.74, reloaded VS Code, retried Start New Agent, and captured fresh logs.
I then compared 0.4.74 and 0.5.74 logs side-by-side.

Result: no behavioral improvement. Both versions showed the same failure signatures.

6. Restore to pre-release

After the A/B test, I switched back to openai.chatgpt-0.5.74 to return to the preferred test state.

7. Evidence collection

I prepared a support bundle containing the key logs and A/B comparison:

  • Bundle directory: .codex_support_20260213_2236
  • Archive: /home/micah/projects/HA_Visual_Dashboard_Maker/codex_vscode_bug_20260213.tar.gz

8. Existing issue check

I checked https://github.com/openai/codex/issues for matching open reports and did not find one that clearly matched this exact error pattern.

Current assessment

Despite reset, cleanup, reinstall verification, and A/B version testing, the failure remained reproducible.
Based on the repeated signatures across both extension versions, this appears more likely to be an upstream extension/runtime bug than a local one-time state issue.

Attachments prepared

  • .codex_support_20260213_2236/AB_COMPARISON.md
  • .codex_support_20260213_2236/remoteexthost_20260213T222845_exthost2.log
  • .codex_support_20260213_2236/Codex_20260213T222845_exthost2.log
  • .codex_support_20260213_2236/remoteexthost_20260213T222845_exthost3_0.4.74.log
  • .codex_support_20260213_2236/Codex_20260213T222845_exthost3_0.4.74.log
  • .codex_support_20260213_2236/rollout-2026-02-13T22-29-07-019c56c3-06fc-7db3-a928-9c3607e17129.jsonl

What steps can reproduce the bug?

Reproduction steps

  1. Open VS Code in WSL remote session.
  2. Activate OpenAI Codex extension.
  3. Click Start New Agent.
  4. Observe failure/errors in extension host logs.
  5. Repeat after full local state reset and after version downgrade/upgrade test.

What is the expected behavior?

Expected

  • New Codex agent/session starts successfully.
  • Conversation thread is created/resumed without rollout lookup errors.

Additional information

codex_vscode_bug_20260213.tar.gz

Activity

  1. BaggyG-AU
    added
    extensionIssues related to the VS Code extension
    on Feb 13, 2026
  2. github-actions
    added
    bugSomething isn't working
    windows-osIssues related to Codex on Windows systems
    on Feb 13, 2026

  3. github-actions commented on Feb 13, 2026

    @github-actions
    github-actionsBot
    on Feb 13, 2026
    Contributor

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

    Powered by Codex Action

  4. donQuiM commented on Feb 13, 2026

    @donQuiM
    donQuiM
    on Feb 13, 2026

    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.

  5. BaggyG-AU commented on Feb 13, 2026

    @BaggyG-AU
    BaggyG-AU
    on Feb 13, 2026
    Author

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

  6. etraut-openai
    changed the title [-]Codex VS Code Extension: "Start New Agent" fails in WSL (both 0.5.74 and 0.4.74)[/-] [+]"Start New Agent" fails in WSL[/+] on Feb 13, 2026
  7. etraut-openai
    changed the title [-]"Start New Agent" fails in WSL[/-] [+]Cannot create new local conversation (WSL)[/+] on Feb 13, 2026

  8. chrisbaber commented on Feb 20, 2026

    @chrisbaber
    chrisbaber
    on Feb 20, 2026

    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.

  9. sstklen commented on Feb 24, 2026

    @sstklen
    sstklen
    on Feb 24, 2026 · Hidden as spam
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingextensionIssues related to the VS Code extensionwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions