[Windows][VS Code] Distinct chats in multiple windows trigger hydration resume storm and active-writer conflicts

Codex version

• VS Code: 1.136.1 (x64)
• Codex IDE extension: openai.chatgpt 26.825.51511
• Bundled Codex CLI/app-server: codex-cli 0.151.0-alpha.7.2
• OS: Windows 11 Home, 10.0.26200 (Build 26200)
• Runtime: native Windows / PowerShell (not WSL)

Summary

Opening multiple VS Code windows on different workspaces, with a distinct Codex chat in each window, causes the extension to automatically hydrate/resume threads owned by other windows. The background resume enters a rapid follower retry loop and eventually produces thread-store conflict: ... already has an active writer errors.

This makes chats appear stuck, prevents queued follow-ups/steering from being delivered, and leaves the history list stale. The user does not open or resume the same chat in multiple windows.

Steps to reproduce

1. Open VS Code window A on workspace A.
2. Open the Codex sidebar and start local chat A.
3. Leave window A and chat A open.
4. Open VS Code window B on a different workspace B.
5. Open the Codex sidebar and create a new local chat B. Do not select or resume chat A.
6. Continue opening/using distinct chats in the two windows.

This is especially visible with four independent VS Code workspaces open concurrently, each using its own active Codex chat.

Expected behavior

Each VS Code window should operate its distinct active chat independently. Loading the shared history in another window should not acquire a writer for, or continuously resume, a thread owned by another window. History and thread ownership should remain synchronized across extension instances.

Actual behavior

The newly opened extension instance sees existing threads in shared history and attempts to resume them as followers. Threads remain in resuming and repeatedly emit maybe_resume_started. Other windows then fail to hydrate those threads because an active writer already exists. Queued follow-ups can fail instead of reaching the active chat.

In one captured VS Code log session:

• One thread emitted 6,620 maybe_resume_started events.
• A second distinct thread emitted 5,952 maybe_resume_started events.
• 12 already has an active writer conflict messages were recorded.
• Failures explicitly identified source=thread_hydration.
• A queued follow-up explicitly failed because the thread already had an active writer.
• No request-timeout pattern was present; authentication succeeded.

Sanitized representative excerpts:

maybe_resume_started conversationId=<redacted> documentVisibilityState=visible hostId=local previousResumeState=resuming previousStreamRole=follower

failed to initialize thread persistence: thread-store conflict: thread <redacted> already has an active writer

Request failed conversationId=<redacted> error={"code":-32600,"message":"thread <redacted> already has an active writer"} method=thread/resume source=thread_hydration

[queued-followups] Failed to send queued follow-up for conversationId=<redacted> reason="thread <redacted> already has an active writer"

Additional context

• Separate workspace folders and separate newly created chats are used in every window.
• The issue appears to be automatic history/thread hydration across extension instances, rather than the same chat being intentionally opened twice.
• Fully exiting all VS Code/Codex processes temporarily releases the writers, but reopening multiple windows reproduces the behavior.
• Related active-writer reports include #37403 and #39823, but those cover macOS Desktop/Remote Control and CLI/TUI session switching rather than distinct chats in multiple Windows VS Code windows.
• Full logs are not attached publicly because they include local paths and session metadata, but sanitized diagnostics or a feedback session can be provided if needed.

Start with the thread/resume entry point and the source=thread_hydration path described in the logs, then inspect how multiple VS Code windows handle shared history and active writers. Reproduce with distinct chats in separate Windows workspaces and verify that threads are not repeatedly resumed, active-writer conflicts stop, and queued follow-ups reach the owning chat.