Repository navigation
[CLI][Remote] “Close it there” is impossible from mobile and does not identify the writer-lock owner #46647
Description
Codex versions
- Standalone CLI:
0.155.0 - Codex bundled with Desktop:
0.149.0-alpha.4 - ChatGPT/Codex Desktop package:
26.818.31338
Operating system
Linux x86_64, kernel 6.17.0-35-generic
What happened?
A Codex conversation was being accessed from the ChatGPT mobile app through Remote. Running codex resume <session-id> on the connected computer displayed:
This conversation is open in another app
Close it there and press R to continue here.
The mobile app has no action to close or release that conversation. Leaving the chat, terminating the mobile app, and even powering off the phone do not release the writer lock. The lock is apparently retained by the Desktop/App Server on the connected host, but the CLI does not identify that owner.
The user is therefore sent to the wrong device and asked to perform an action that does not exist in the mobile UI. The practical recovery is to terminate the Desktop app or exit the blocked TUI and run codex fork <session-id>.
Steps to reproduce
- Enable Remote on a computer running the Desktop app.
- Open or continue a Codex conversation from ChatGPT mobile through Remote.
- On the host, run
codex resume <session-id>for that conversation. - Observe the “open in another app” screen.
- Close/force-stop the mobile app or power off the phone.
- Press
Rin the CLI.
Actual result
The conversation remains blocked. The CLI neither identifies the Desktop/App Server as the writer-lock owner nor provides a way to release, hand off, or fork the conversation.
Expected result
At least one of the following:
- Identify the actual writer-lock owner and host, for example
Codex Desktop on <host>. - Provide an explicit handoff/release action in Remote/Desktop.
- Offer
Fork conversationdirectly from the blocked TUI. - Replace
Close it therewith instructions that are possible in the relevant client.
Related issue
Related UX request: #44764. This report is specifically about incorrect/unactionable lock-owner guidance in a Remote/mobile workflow.
Activity
github-actions commentedon Sep 19, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
peixotorms commentedon Sep 22, 2026
This is an example of something unnecessary. It should just takeover and thats it.
jatmn commentedon Sep 24, 2026
Same issue here
Codex 26.917.62051
niffnuff commentedon Oct 3, 2026
I can reproduce this in both directions on the current Work Desktop/Codex build, which makes this look like a session handoff regression rather than a stale-lock edge case.
Direction 1: Desktop -> Remote/mobile
Direction 2: Remote/mobile -> Desktop
This is open in another app. Close it there to continue here.Closing/leaving the Remote UI does not provide a usable handoff. The underlying Codex process on the host remains the writer owner.
This breaks the core Remote workflow: starting, monitoring, or continuing work from one device and then moving back to the other.
In one reproduced case I inspected the running session directly:
0.153.415:59:42local time while working on EP06-EP07.427105,/usr/lib/chatgpt/resources/codex, still held the session's exclusive writer lock.Expected behavior would be either:
Take over here/ writer-handoff action that transfers ownership safely.The current behavior makes Remote effectively unusable for device handoff because whichever client/runtime owns the writer blocks the other direction as well.
I have a screenshot showing the live Codex process retaining the exclusive writer lock while Desktop reports that the conversation is open in another app.
forangel2014 commentedon Oct 16, 2026
just rename/delete .codex/thread-writer-locks can solve this