Repository navigation
[Windows][VS Code] Distinct chats in multiple windows trigger hydration resume storm and active-writer conflicts #42589
Description
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
- Open VS Code window A on workspace A.
- Open the Codex sidebar and start local chat A.
- Leave window A and chat A open.
- Open VS Code window B on a different workspace B.
- Open the Codex sidebar and create a new local chat B. Do not select or resume chat A.
- 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_startedevents. - A second distinct thread emitted 5,952
maybe_resume_startedevents. - 12
already has an active writerconflict 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 [macOS][regression] Desktop cannot resume Remote Control / CLI thread:
already has an active writerafter latest update #37403 and [CLI][TUI] Session resume can fail with 'already has an active writer' after approval-mode use or session switching #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.
Activity
jejucoding101 commentedon Sep 5, 2026
Independent reproduction on Windows, with a generated-image preview as the trigger.
Environment
1.136.1(x64)openai.chatgpt 26.5901.2233410.0.19045.7184Trigger and visible result
This also overlaps with #38133, but the extension logs expose the multi-window hydration/ownership conflict described in this issue.
Sanitized diagnostics
Immediately after the target webview became inactive, the other two VS Code extension hosts received these broadcasts:
Both extension hosts then attempted to resume the target thread even though those windows had different workspaces and distinct active conversations:
One of those windows had previously resumed its own distinct thread successfully, with Git/workspace activity tied to a different project. A few minutes later the same extension host successfully resumed the target thread. This suggests that the selected thread/route or hydration event crossed VS Code window/workspace boundaries; it was not caused by the user opening the same chat twice.
The local rollout file for the affected conversation remained present, was about 108 MB, and continued updating after the UI became blank. This appears to be a hydration/rendering failure rather than transcript deletion.
Expected
owneror resume a thread selected in another window.Fully exiting all VS Code processes releases the writer and temporarily restores access when reopening a single window.