Feature request: idempotent task creation and explicit phone ↔ Codex Desktop ownership handoff
What variant of Codex are you using?
Codex App + ChatGPT iPhone Remote + local app-server automation
What feature would you like to see?
I have a concrete cross-device automation use case that would benefit from first-class support.
An iPhone Voice Memo syncs to an always-on Mac, where a local daemon detects it, transcribes it locally, and generates a Codex prompt. The daemon then needs a supported way to create one official Codex task that is immediately visible in the ChatGPT/Codex iPhone app while the Mac is locked but awake and online. Later, the user should be able to continue that same task in Codex Desktop, and then continue it again from the phone.
The difficult part is not transcription. It is task creation, mobile visibility, and thread ownership across Codex hosts. In current experiments, using a standalone app-server/Remote host can make the task visible on mobile, but attaching or continuing the same thread from Codex Desktop may lead to an active-writer or “opened in another app” conflict. Recovering requires an explicit release/resume sequence.
Requested capabilities:
- A supported local API for idempotent task creation, returning the canonical thread ID and a durable receipt.
- Immediate mobile visibility/notification for a newly created task.
- Explicit atomic ownership handoff between the mobile Remote host and Codex Desktop.
- A visible owner/state indicator and fail-closed handling of conflicting writers.
- Safe sequential continuation on phone → Mac → phone without duplicate turns, forks, or manual database changes.
Simultaneous multi-writer editing is not required. A reliable sequential handoff would fully satisfy this workflow.
Additional information
Related context: #31114, #35800, #37620, and discussion #14067.
This request focuses on a supported creation-and-ownership protocol rather than transcription. Identifying account, host, environment, local path, recording, and thread details have intentionally been omitted from this public report.
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
+1 — this is exactly the ownership model I need, and I can reproduce the current failure bidirectionally on Windows with VS Code + Remote Control, using an iPhone as the mobile client.
I would strongly prefer a “Take over here” button rather than treating the thread as unavailable when another client currently owns it.
The current single-writer constraint makes sense for preventing two clients from modifying the same thread concurrently, but I don’t think it should imply single-client access.
The desired behavior would be:
For example:
VS Code owns thread → iPhone opens read-only → Take over here → iPhone becomes writer → VS Code becomes read-onlyIf an active turn is still running, two useful options could be:
I can reproduce the current behavior reliably on Windows.
When VS Code owns the thread, the VS Code extension’s bundled
codex.exeholds:~/.codex/thread-writer-locks/<thread-id>.lockOpening the same conversation from the iPhone then fails because the Remote app-server cannot acquire the writer lock:
thread-store conflict: thread <id> already has an active writerHowever, the iPhone UI does not explain that this is an ownership conflict. It only shows the generic error:
Error loading messages.This is particularly confusing because the conversation still appears normally in the conversation list, so from the user’s perspective it looks like a message-loading or synchronization failure rather than an intentional ownership restriction.
At minimum, I think the mobile UI should show something explicit, for example:
This thread is currently open in VS Code.with actions such as:
View read-onlyTake over hereThe reverse direction is already somewhat clearer. When the iPhone/Remote app-server owns the thread first, VS Code shows:
This is open in another appClose it there to continue here.I verified at the OS level that in this case the Remote
codex.exeis indeed holding the same thread writer lock.I also verified that simply closing the ChatGPT app on the iPhone does not necessarily release ownership. The Remote app-server can continue holding the writer lock until that process is stopped, after which VS Code can immediately open the thread again.
So the underlying single-writer locking appears to work correctly. What seems to be missing is:
For my workflow, simultaneous multi-writer support is not needed at all. A reliable “Take over here” operation, while preserving the invariant that only one client can write at a time, would fully solve the problem.
Environment: