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

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

VS Code extension: Existing chat thread gets stuck only in one workspace until thread receives a new response elsewhere #18963 describes workspace-specific stuck threads, but not the explicit ownership message.
VS Code Codex chat webview turns gray while app-server continues running #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.

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

0.147-alpha (Windows): App keeps thread writer for every opened thread until full app exit; no attach path for external clients #37450
[macOS][regression] Desktop cannot resume Remote Control / CLI thread: already has an active writer after latest update #37403

Powered by Codex Action

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

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."

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.

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.

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

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.

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.

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.

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.

Not working.

This is a very frequent situation when used with Remote shell extension. If the remote connection gets severed for any reason, then you cannot connect back to that remote chat session; Happening with the latest vscode Codex Plugin v26.903.71938 also

This is a very frequent situation when used with Remote shell extension. If the remote connection gets severed for any reason, then you cannot connect back to that remote chat session; Happening with the latest vscode Codex Plugin v26.903.71938 also

Happens all the time!

@xiangtaowong

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.

Worked for me, you saved my day @xiangtaowong

should be pkill -TERM -u "$USER" -f '[c]odex.*app-server' instead of ending with " though

On WSL Ubuntu I had to do this instead to get back into my previous session:
pkill -TERM -u "$USER" -f '[c]odex.*'

I have the same issue.

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

I have the same issue.
pkill -TERM -u "$USER" -f '[c]odex.*' would restart the codex server. But it doesn't solve my issue. It is still showing the same message after restart.

Try using the codex through Traycer - that problem is drastically reduced (for remote connections)

@

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.

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

+1 Same issue under this environment sshing

Environment:

CachyOS Linux 7.2.2-1-cachyos

Vs Code

Remote SSH to Ubuntu Linux box

Official Vs Code Codex Extention

Chatgpt Plus

I have the same issue. pkill -TERM -u "$USER" -f '[c]odex.*' would restart the codex server. But it doesn't solve my issue. It is still showing the same message after restart.

Resolved my issue, thank you

Additional occurrence on 2026-09-20: after restarting the PC, every previously usable Codex session I tried in multiple VS Code instances refused to resume with:

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

Retry did not recover the conversations. The same failure also appears after merely restarting VS Code. No actionable owning app or session is identified, so the proposed instruction to close it elsewhere gives the user no way to proceed. A full PC restart should clear local process ownership; if the blocker is remote or persisted state, the UI must explain and provide a safe takeover or release path.

This is a severe basic reliability failure for a paid coding tool. It blocks access to existing work across the IDE after an ordinary restart. A session resume path that cannot recover from a stale owner would not pass basic startup quality control. Please treat recovery as a product requirement: expire dead writer ownership, identify any genuinely live owner, and give the user an explicit safe takeover action. The dialog must not strand the user with Retry as the only available operation.

I have not captured process-level evidence, so stale writer ownership is a plausible interpretation of the UI state, not an established root cause. The screenshot includes private project content and is intentionally withheld.

Additional reproduction evidence for VS Code Remote-SSH with extension openai.chatgpt 26.928.31416-linux-x64.

Client: macOS, VS Code desktop. Remote extension host: Linux x86_64. The extension launches its bundled Codex app-server via a local proxy wrapper. Subscription tier and exact OS/VS Code versions were not collected.

After a network disconnect and reconnect / Reload Window, the existing conversation showed:

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

No other visible window for this conversation was open according to the user.

Observed timeline

Times below are from the remote logs (2026-10-01 to 2026-10-02); this is an observed incident, not a separately validated deterministic reproduction.

23:20:19: the old VS Code management connection disconnected. The server logged: The client has disconnected, will wait for reconnection 3h before disposing...
00:15:06: a new client connected. The old connection logged: Another client has connected, will shorten the wait for reconnection 5m before disposing...
00:17:38–00:17:41: a subsequent reload cleanly exited the newly connected extension host and started another extension host / Codex app-server. The original disconnected extension host was still alive.
00:17–00:18: attempts to resume the affected thread repeatedly failed with thread-store conflict: thread <redacted> already has an active writer. The thread/resume request returned error code -32600.
Process inspection during the failure showed two extension-host trees, each with its own bundled Codex app-server: the original tree started at 21:26, and the current tree started at 00:17.
00:20:07: VS Code logged The reconnection short grace time of 5m has expired, so the connection will be disposed. The original extension host then exited with code 0.
A subsequent process check confirmed that the original Codex app-server and its code-mode child had also exited; only the current extension-host / app-server tree remained. No processes were manually killed and no lock files were removed.

The extension-host logs explicitly report VSCODE_RECONNECTION_GRACE_TIME=10800000ms (10800s).

Interpretation and limits

This supports a disconnected-but-still-live remote extension host retaining the thread writer while a replacement client tries to resume it. It does not establish a deadlock or a lock left behind by an already-dead process. The exact lock owner was not independently traced via file descriptors, and successful UI recovery after the old process exited was not verified.

Expected behavior

The UI should explain that a disconnected remote client may still own the thread, and offer a safe recovery/retry path. Ownership handoff or recovery should preserve single-writer guarantees and any ongoing work; blindly deleting a lock or terminating a possibly active agent is not an appropriate general fix.

This adds Remote-SSH evidence and the explicit 3-hour / 5-minute reconnection-grace timeline to the existing VS Code Web report. Related plain-SSH lifecycle report: #44063.

Hostnames, IP addresses, usernames, private paths, thread IDs, and conversation contents have been omitted.

Workaround: Fix "This is open in another app" in the VS Code Codex Extension

I encountered the following error when trying to continue an existing Codex CLI conversation in the VS Code Codex extension:

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

I was able to resolve the issue by identifying and terminating an existing Codex CLI process that was still holding the session lock files.

Root Cause

Codex uses per-thread lock files under:

~/.codex/thread-writer-locks/

If a conversation was previously opened through Codex CLI, the CLI process may still be running and holding the session lock, even when the terminal is no longer actively being used.

When the VS Code extension attempts to resume the same conversation, it may fail to acquire the session lock and display the "This is open in another app" message.

Important: Having only one VS Code Codex app-server process does not necessarily mean that no other Codex process is holding the session lock.

Solution (macOS / Linux)

Step 1: Find processes accessing Codex session lock files

Run:

lsof -nP +D "$HOME/.codex/thread-writer-locks"

Example output:

COMMAND   PID    USER    FD   TYPE  NAME
codex     22287  user    38u  REG   .../thread-writer-locks/<thread-id-1>.lock
codex     22287  user    48u  REG   .../thread-writer-locks/<thread-id-2>.lock

This shows that process 22287 has two session lock files open.

Note that lsof identifies processes with open file descriptors; it does not by itself prove that a process currently holds an exclusive lock. However, it is a useful way to identify potential lock owners.

Step 2: Identify the Codex processes

Run:

ps -axo pid,ppid,etime,command | grep -Ei '[c]odex|[c]hatGPT'

Example output:

65919  65689  03:40     .../openai.chatgpt-.../bin/.../codex ... app-server
22287  35945  03:54:48  codex --approve-for-me
24592  22287  03:52:30  .../codex-code-mode-host

In this example:

65919 is the VS Code Codex extension's app-server.
22287 is an existing Codex CLI process.
24592 is a child process of the Codex CLI.

The CLI process (22287) is the same process that appeared in the lsof output.

This strongly suggests that the existing CLI session is preventing the VS Code extension from taking over the conversation.

Step 3: Exit the existing Codex CLI session

If the original CLI terminal is still available, exit Codex normally:

/exit

If the original terminal is unavailable, first confirm that the process is no longer performing any important work:

ps -p 22287 -o pid,ppid,etime,command

Then terminate it gracefully:

kill -TERM 22287

Replace 22287 with the actual PID found in Step 1.

Warning: Terminating a Codex process may interrupt ongoing tasks. Make sure the process is idle or no longer needed before terminating it.

Step 4: Verify that the lock files are no longer open

Run:

lsof -nP +D "$HOME/.codex/thread-writer-locks"

Verify that the previous CLI PID no longer appears.

Other lock files may still be open if other Codex sessions are active.

Step 5: Reload VS Code

In VS Code:

Open the Command Palette (Cmd + Shift + P on macOS or Ctrl + Shift + P on Linux).
Select Developer: Reload Window.
Reopen the affected Codex conversation.
Try continuing the conversation.

In my case, the original conversation became accessible again after the existing CLI process was terminated.

Important Notes

Do not delete ~/.codex to fix this issue. It contains session history and configuration.
Do not manually delete .lock files while another process may still be using them. Removing a lock file does not necessarily release an OS-level lock.
Multiple Codex processes are not inherently a problem. The issue occurs when the same conversation cannot be acquired by the new client.
This issue can occur even if there is only one VS Code Codex app-server process.
The same troubleshooting approach may help when switching between Codex CLI, the VS Code extension, and other Codex clients.

Summary

The workaround that resolved my issue was:

Identify processes accessing ~/.codex/thread-writer-locks/ using lsof.
Find the corresponding Codex CLI process using ps.
Exit or gracefully terminate the old CLI process.
Verify that the old process has released the lock files.
Reload VS Code and reopen the conversation.

Navigation Menu

Repository navigation

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

Summary

Environment

Observed sequence

Diagnostic evidence

Expected behavior

Actual behavior

Related issues

Observed timeline

Interpretation and limits

Expected behavior

Workaround: Fix "This is open in another app" in the VS Code Codex Extension

Root Cause

Solution (macOS / Linux)

Step 1: Find processes accessing Codex session lock files

Step 2: Identify the Codex processes

Step 3: Exit the existing Codex CLI session

Step 4: Verify that the lock files are no longer open

Step 5: Reload VS Code

Important Notes

Summary

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Summary

Environment

Observed sequence

Diagnostic evidence

Expected behavior

Actual behavior

Related issues

Activity

github-actions commented on Aug 10, 2026

trulko commented on Aug 11, 2026

Jimbernator commented on Aug 12, 2026

Zenine commented on Aug 19, 2026

alahlko commented on Aug 23, 2026

dan-justiniac commented on Aug 24, 2026

xiangtaowong commented on Aug 25, 2026

Anlittledy commented on Aug 26, 2026

cuiyoutian commented on Sep 2, 2026

KrishnaPG commented on Sep 10, 2026

cuiyoutian commented on Sep 10, 2026

LYC-vio commented on Sep 12, 2026

monopoly-db commented on Sep 13, 2026

AMDarter commented on Sep 14, 2026

qzhu2017 commented on Sep 16, 2026

KrishnaPG commented on Sep 17, 2026

maroc-dev commented on Sep 18, 2026

maroc-dev commented on Sep 18, 2026

elfege commented on Sep 20, 2026

hairongChenDavid commented on Oct 1, 2026

Observed timeline

Interpretation and limits

Expected behavior

Y7cc commented on Oct 9, 2026

Workaround: Fix "This is open in another app" in the VS Code Codex Extension

Root Cause

Solution (macOS / Linux)

Step 1: Find processes accessing Codex session lock files

Step 2: Identify the Codex processes

Step 3: Exit the existing Codex CLI session

Step 4: Verify that the lock files are no longer open

Step 5: Reload VS Code

Important Notes

Summary

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions