VS Code extension: stale thread owner blocks chat with “open in another application” (autogen selfreport from codex)

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

1. Open a Codex thread in one VS Code Web window.
2. Connect another VS Code Web window to the same remote host and Codex state.
3. Reload or disconnect one window while the Codex webview is starting.
4. Open or continue the thread from another live window.
5. Codex reports that the chat is open in another application.
6. 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

• #18963 describes workspace-specific stuck threads, but not the explicit ownership message.
• #35598 reports gray webviews and unhandled thread-stream-following-changed broadcasts, but not stale ownership or takeover.

No usernames, hostnames, IP addresses, local paths, account identifiers, thread IDs, or raw logs are included.

Start by tracing thread ownership in the app-server and the handling of the thread-stream-following-changed broadcast. Reproduce the reload or disconnect sequence across multiple VS Code Web windows and inspect the extension-host termination timing. Done means a disconnected client no longer blocks a live client, ownership is identifiable, and takeover or release works without affecting separate threads.