Summary
The VS Code extension can leave a thread owned by another Codex client after a VS Code Web renderer reloads or disconnects.
A different live client then shows the localized equivalent of:
This chat is open in another application. To continue here, close the chat elsewhere.
The UI does not identify the owning client. It also provides no supported way to release a stale owner or take over the thread.
Environment
- Codex VS Code extension:
openai.chatgpt 26.803.41515-linux-x64
- VS Code Web:
1.132.0
- Extension host: Linux x86_64
- Browser client: Firefox
153.0.3 on Windows 11
- Several VS Code Web windows connected to the same remote Codex state
Observed sequence
- Open a Codex thread in one VS Code Web window.
- Connect another VS Code Web window to the same remote host and Codex state.
- Reload or disconnect one window while the Codex webview is starting.
- Open or continue the thread from another live window.
- Codex reports that the chat is open in another application.
- The user must find and close stale clients or terminate processes manually.
The problem is intermittent, but the process and log state is consistent when it occurs.
Diagnostic evidence
Each VS Code extension host starts a separate child process:
extensionHost
└─ codex ... app-server --analytics-default-enabled
Several of these app-server instances can remain active at the same time.
Multiple extension logs receive the same broadcast:
[IpcClient] Received broadcast but no handler is configured method=thread-stream-following-changed
A disconnected extension host can remain alive until the renderer reconnection grace period expires:
Extension host terminating: renderer disconnected for too long (2)
The thread data remains present. Authentication and model requests are not the failure. The blocking state is thread ownership or stream-following state.
Expected behavior
- Release thread ownership promptly when its webview or client disconnects.
- Do not let an app-server owned only by a disconnected renderer block another live client.
- Identify the owning client in the error message.
- Provide a Take over here action that safely invalidates a stale owner.
- Keep separate threads and workspaces independent when several VS Code windows are active.
Actual behavior
A stale or duplicate client can block an active thread with no recovery action in the UI. This is disruptive for long-running tasks and multi-window workflows.
Related issues
No usernames, hostnames, IP addresses, local paths, account identifiers, thread IDs, or raw logs are included.
Summary
The VS Code extension can leave a thread owned by another Codex client after a VS Code Web renderer reloads or disconnects.
A different live client then shows the localized equivalent of:
The UI does not identify the owning client. It also provides no supported way to release a stale owner or take over the thread.
Environment
openai.chatgpt 26.803.41515-linux-x641.132.0153.0.3on Windows 11Observed sequence
The problem is intermittent, but the process and log state is consistent when it occurs.
Diagnostic evidence
Each VS Code extension host starts a separate child process:
Several of these app-server instances can remain active at the same time.
Multiple extension logs receive the same broadcast:
A disconnected extension host can remain alive until the renderer reconnection grace period expires:
The thread data remains present. Authentication and model requests are not the failure. The blocking state is thread ownership or stream-following state.
Expected behavior
Actual behavior
A stale or duplicate client can block an active thread with no recovery action in the UI. This is disruptive for long-running tasks and multi-window workflows.
Related issues
thread-stream-following-changedbroadcasts, but not stale ownership or takeover.No usernames, hostnames, IP addresses, local paths, account identifiers, thread IDs, or raw logs are included.