›_ Codex Issues
Codex Issues / #37856

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

Open 💬 8 comments Opened Aug 10, 2026 by nos1609
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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.

View original on GitHub ↗

8 Comments

github-actions[bot] contributor · 17 days ago

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

  • #37450
  • #37403

Powered by Codex Action

trulko · 16 days ago

I am experiencing the exact same issue in the exact same set of circumstances. I am on Ubuntu 24.04, in VScode 1.132, Codex 26.803.61601

Jimbernator · 16 days ago

I also started seeing this issue on August 9th. Started simulataneously to both work and personal Codex account.
Still seeing issue on:
Codex VS Code extension:26.803.61601
Windows 11.

The two exact messages I get when trying to open the chat are:
• "Error creating chat thread 019** already has an active writer"
• "This task is active elsewhere. Close it there, then retry here."

Zenine · 8 days ago

Confirmed on VS Code Remote-SSH with the Codex extension openai.chatgpt 26.5814.41407-linux-arm64.

Observed evidence:

  • After a Remote-SSH reconnect, the previous pair of VS Code extension-host processes remained alive while a new pair was started under the same remote VS Code server.
  • Each old extension host retained its own child Codex app-server, so the old and current Codex backends coexisted.
  • One stale backend still had the affected rollout/session file open. The file had stopped changing and its last lifecycle event was turn_aborted, but the old UI continued to display Thinking and would not accept or return messages.
  • The stale processes were sleeping in futex_wait_queue / ep_poll; the newly connected extension host had a separate active app-server.
  • Sending targeted SIGTERM to only the two old extension-host process trees removed their stale Codex app-servers. The current extension host, current Codex backend, remote VS Code server, and long-lived Codex MCP service remained running.

This confirms that Remote-SSH reconnection can leave the previous extension-host/app-server generation alive and preserve stale thread/UI ownership even when the corresponding turn is no longer running. Reconnect should retire the old generation or release its thread/stream-following state before activating the replacement.

alahlko · 4 days ago

I'm experiencing this exact issue with the Codex VS Code extension.

In my case, Codex is NOT open in another application, another VS Code window, the Codex desktop app, or another browser/IDE.

I have only one VS Code instance open, connected through Remote SSH, and Codex still displays:

"This is open in another app. Close it there to continue here."

Clicking Retry does not resolve it.

This appears to be a stale thread ownership / app-server state rather than an actual second Codex client.

Environment:

  • Windows 11 client
  • VS Code
  • Remote SSH to Linux
  • Official OpenAI Codex VS Code extension
  • ChatGPT Plus

Screenshot available showing the error.

<img width="1097" height="1032" alt="Image" src="https://github.com/user-attachments/assets/64c19795-c7cd-4e25-9091-9d0c44d2b14f" />

Please add a "Take over here" / force-release mechanism, or automatically clear stale ownership when the previous app-server/client is no longer active.

dan-justiniac · 3 days ago

Same deal breaker for a task started with the CLI on a host, and monitoring/steering from the app's "remote" thread (desktop and mobile). The thread is harder to "expose" in the app, and once it's visible, any attempt to interact with it is now verboten.

<img width="756" height="90" alt="Image" src="https://github.com/user-attachments/assets/66c027cf-a1f9-468b-810d-0f891bd00593" />

xiangtaowong · 2 days ago

This can be solved by running "pkill -TERM -u "$USER" -f '[c]odex.*app-server" on terminal after closing all the IDE. However, this's only a temporary solution.

Anlittledy · 1 day ago

I reproduced the same ownership issue on Windows with VS Code + iPhone Remote Control. I added OS-level writer-lock evidence and a proposed “Take over here” ownership handoff flow in #40157.