[macOS][Android Remote][VS Code] Remote cannot open VS Code-owned thread; writer remains held after Android disconnects

What version of the Codex App are you using (From “About Codex” dialog)?

Powered by Codex & OWL Version 26.820.60940

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Darwin 24.6.0 arm64 arm

What issue are you seeing?

Android Remote can no longer open a Codex thread that is currently owned by
the Codex VS Code extension.

This workflow used to work for me: I could start a long-running Codex task
from VS Code, leave my computer, and later open the same session from the
ChatGPT Android app using Remote Control to monitor or continue it.

With the current versions, opening that thread from Android hangs indefinitely
on the loading/connecting state.

The macOS host logs show that Android Remote reaches the app-server and issues:

app_server.client_name="codex_chatgpt_android_remote"
rpc.method="thread/resume"

but the request fails with:

thread-store conflict:
thread <redacted> already has an active writer

Other older threads that are not currently owned by VS Code open normally
from Android, so Remote connectivity and pairing are working.

If I run Developer: Reload Window in the VS Code window, the writer is
released and Android can immediately open the same thread.

The inverse direction then fails: after Android opens the thread, VS Code
shows:

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

Closing the Android app, including removing it from the Android recent-apps
screen, does NOT release the thread.

Using lsof on the thread writer lock showed that the lock was held by a
codex app-server process whose direct parent was the macOS ChatGPT/Codex
Desktop app.

After fully quitting Codex/ChatGPT Desktop on the Mac, that process exits,
the writer is released, and VS Code can immediately open the thread again.

So there appear to be two related problems:

1. Android Remote tries to resume/acquire a writer for a VS Code-owned thread

instead of following the already active session.

1. Once Remote becomes the owner, closing the Android client does not release

the writer; the macOS Codex App app-server continues holding it until the
desktop app is fully quit.

The affected rollout itself is readable and parses successfully with zero
parse errors.

What steps can reproduce the bug?

1. On macOS, open a Codex conversation from the Codex VS Code extension.
2. Start a turn in that conversation, or leave the conversation loaded after

completing a turn.

1. Leave VS Code running with that thread still owned by its Codex app-server.
2. From the ChatGPT Android app, connect to the Mac using Codex Remote Control.
3. Try to open the same conversation.

Result:

• Android remains indefinitely on the loading/connecting screen.
• macOS logs show codex_chatgpt_android_remote issuing thread/resume.
• The request fails with `thread-store conflict: thread <id> already has an

active writer`.

1. On the Mac, run Developer: Reload Window in that VS Code window.
2. Without any other change, try opening the conversation again from Android.

Result:

• Android can now open the conversation.

1. While the conversation is open on Android, try to open it again from VS Code.

Result:

• VS Code displays:

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

1. Close the ChatGPT Android app and remove it from Android recent apps.
2. Try opening the conversation again from VS Code.

Result:

• VS Code still reports that it is open in another app.
• The thread writer lock is still held by a macOS codex app-server process

whose parent is ChatGPT/Codex Desktop.

1. Fully quit Codex/ChatGPT Desktop on macOS.
2. Try opening the conversation again from VS Code.

Result:

• The writer is released and the conversation opens immediately.

What is the expected behavior?

A thread that is already active in the VS Code extension should remain
accessible through Android Remote without requiring a second writer.

Ideally, Remote should attach to the existing owner as a follower so that I
can:

• read the current conversation/history;
• observe a long-running turn;
• answer permission or elicitation requests;
• steer or interrupt the active turn;
• send the next instruction through the existing owner.

If exclusive ownership must move between clients, there should instead be an
explicit and safe handoff / "Take over here" mechanism.

Closing or disconnecting the Android Remote client should also promptly
release any ownership acquired on its behalf, rather than requiring the
macOS Codex Desktop app to be fully quit.

Additional information

This appears to be a recent regression in Codex thread ownership / writer
handoff.

The workflow of starting a long-running task in VS Code and later accessing
the same thread from mobile Remote Control worked previously.

This is particularly disruptive for unattended work: I often start a
long-running Codex task in VS Code and then leave the computer. Once I am
away from the Mac, I cannot run Developer: Reload Window, so there is no
way to regain access to that thread through Android Remote.

Diagnostic details:

• VS Code Codex extension: 26.820.60940
• Codex runtime observed in VS Code logs: 0.150.0
• Android Remote client name in host logs:

codex_chatgpt_android_remote

• Affected rollout parsed successfully with zero parse errors.
• Other threads without an active writer open normally through Remote.
• The writer lock was confirmed with lsof.
• When Remote owned the thread, the lock holder was a codex app-server

process parented by the macOS ChatGPT/Codex Desktop application.

• Closing Android did not release it.
• Fully quitting the macOS Codex Desktop application did.

Related existing reports:

• #40167
• #37403
• #37856

My case differs in that it reproduces the complete VS Code -> Android Remote
-> VS Code lifecycle and confirms which macOS process retains the writer
after the Android client has disconnected.