Graceful thread handoff between desktop Codex and the mobile bridge

[ltspace]

Problem

We have not found a reliable, graceful way to hand off an existing Codex thread between the desktop Codex client and the mobile bridge.

Both clients can contend for the same thread writer lock. When one side still owns the writer, the other side may fail with errors such as thread-store conflict, already has an active writer, or our mapped thread_in_use response. From the user's perspective, the desktop or phone can look idle while the underlying writer lock is still held.

What we have tried

• Calling thread/unsubscribe after a turn completes
• Waiting for pending unsubscribe/release work before resuming a thread
• Queuing mobile messages while another writer owns the thread
• Detecting the exact lock owner and offering a guarded takeover
• Recycling only the bridge-owned Codex App Server after the final mobile client disconnects and all work is idle

These measures reduce failures, but they are still workarounds. In particular, thread/unsubscribe can leave the thread unloaded while its writer lock remains for a significant period, and process recycling or forced takeover can interrupt other threads owned by the same process.

Desired behavior

We would like a clean ownership/handoff model where:

1. Desktop and mobile can discover who currently owns the thread writer.
2. An idle owner can release or transfer ownership promptly and explicitly.
3. Active turns are never interrupted.
4. A process that owns multiple threads does not need to be terminated just to release one thread.
5. Disconnects and stale clients are handled without long lock retention or manual recovery.

Help wanted

We would appreciate ideas, relevant Codex App Server lifecycle details, or implementation suggestions for a robust per-thread handoff protocol. If there is a better supported sequence than thread/unsubscribe / thread/resume, or another API for releasing writer ownership, please share it.