[VS Code Remote-SSH] Server reconnect leaves stale app-server holding thread writer; new session blocked by “This is open in another app”

Summary

A Remote-SSH disconnect / remote server failure can leave the old VS Code Server extension host and Codex app-server alive. After reconnecting, VS Code starts a second VS Code Server + second Codex app-server. The stale first app-server continues to hold the thread writer, so the newly connected session is blocked with:

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

There is no other usable app/window to close because the original Remote-SSH connection is already gone.

This is especially disruptive for paid users because a normal SSH/server failure can make an existing Codex conversation unusable until the user manually inspects and kills remote processes.

Environment

• VS Code Remote-SSH
• Remote host: Linux x86_64
• Codex extension runs on the remote VS Code Server
• Old Codex extension instance:
  • openai.chatgpt-26.818.22352-linux-x64
• New Codex extension instance after reconnect:
  • openai.chatgpt-26.825.51511-linux-x64

What happened

1. Codex was being used normally through VS Code Remote-SSH.

2. The remote server / SSH connection failed.

3. The user reconnected to the same server.

4. VS Code started a new remote server / extension host.

5. Opening the same Codex thread showed:

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

6. The original client could not be closed because that connection had already died.

7. Process inspection on the remote server showed two simultaneous VS Code Server trees and two simultaneous Codex app-server processes.

Diagnostic evidence

The stale process tree had been alive for ~45 minutes:

PID 1986  ... /.vscode-server/code-110a328ea54b42367b803ec53ee0bf52ef26b419 ... agent host
PID 1997  ... Stable-110a328ea54b42367b803ec53ee0bf52ef26b419/server/bin/code-server ...
PID 2001  ... Stable-110a328ea54b42367b803ec53ee0bf52ef26b419/server/out/server-main.js ...
PID 2028  ... bootstrap-fork --type=extensionHost ...
PID 2196  ... /extensions/openai.chatgpt-26.818.22352-linux-x64/bin/linux-x86_64/codex -c features.code_mode_host=true app-server --analytics-default-enabled

After reconnecting, a second process tree existed for ~3 minutes:

PID 9296  ... Stable-08d4889f9ec4a1685d257b9b95de036c8e1ce1e5/server/out/server-main.js ...
PID 9323  ... bootstrap-fork --type=extensionHost ...
PID 9501  ... /extensions/openai.chatgpt-26.825.51511-linux-x64/bin/linux-x86_64/codex -c features.code_mode_host=true app-server --analytics-default-enabled

So the topology was effectively:

stale Remote-SSH session
  └─ old VS Code Server
      └─ old extensionHost
          └─ old codex app-server   <-- stale writer remains

new Remote-SSH session
  └─ new VS Code Server
      └─ new extensionHost
          └─ new codex app-server   <-- blocked by active writer

The codex command is not globally installed or on $PATH; it is bundled inside the remote openai.chatgpt extension. Therefore CLI recovery commands such as codex doctor are not available from a normal remote shell unless the bundled binary path is used explicitly.

Expected behavior

A dead Remote-SSH / renderer / extension connection must not leave a permanent writer lock.

At least one of the following should happen:

• writer ownership should automatically expire after the owning client disconnects;
• the remote extension host/app-server should shut down when its client is gone;
• reconnecting should detect and reuse or safely replace the stale owner;
• the UI should provide a Take over here action;
• the error should identify which host/process owns the writer and provide a supported way to revoke it.

Users should not have to SSH into the server, inspect process trees, and manually kill stale Codex processes just to recover their own conversation after a network/server failure.

Related

This appears closely related to #37856 (stale thread owner in VS Code) and other already has an active writer reports, but this reproduction specifically shows a Remote-SSH reconnect creating two different VS Code Server builds and two Codex app-server instances on the same remote Linux host after the original connection failed.

Start with the Remote-SSH reconnect lifecycle and the Codex app-server writer-ownership entry point described in the reproduction. Reproduce the failed connection, reconnect, and two simultaneous remote process trees, then trace how the stale owner survives. Done means a disconnected owner no longer permanently blocks the new session and recovery is covered by a test or clearly validated behavior.