What variant of Codex are you using?
CLI + ChatGPT iOS Remote Control (paired hosts)
What feature / fix would you like?
Support the normal workstation-primary workflow:
- Start and run the task in Codex CLI on the workstation
- Use the phone only to monitor progress, approve actions, and send short steering replies
- Return to the same live CLI session without quit/resume or forking
Today, Remote Control effectively allows the phone to open completed threads, but fails when the workstation CLI already owns a live / in-progress session.
Why this matters
Almost nobody’s main coding surface is the phone. The realistic loop is:
- keyboard + terminal on the workstation
- phone as a second screen for status + decisions while away from the desk
Claude Code Remote Control (/rc) matches this model: the local CLI session stays primary; mobile is another window into the same live session.
Codex Remote currently behaves more like: “pair a host → operate threads from mobile,” and does not reliably share an already-attached live CLI session with iOS.
What happens today (observed)
| Session state |
iOS Remote result |
| Completed (no active CLI attach) |
Opens and reads normally |
| Live / in-progress CLI session |
Fails to load |
On the failing live session, iOS shows:
加载消息时出错:Codex 服务器返回了错误。
(“Error loading messages: Codex server returned an error.”)
此任务无法重新连接
(“This task cannot reconnect”)
So the phone can act as a history viewer for finished threads, but cannot attach to the live session the CLI already owns.
Expected behavior
- Workstation CLI remains the primary client
- iOS can attach to that same live thread as a secondary client
- Monitoring, approvals, and short follow-ups work without forcing the user to start the task from mobile
- Returning to the workstation TUI does not require quitting and
resume, and does not create divergent continuations
Actual behavior
- Completed threads: OK from iOS
- Live CLI-attached threads: iOS cannot reconnect / server error
- Practical workaround pushed by the product shape: start work from Remote/App side instead of CLI — awkward for workstation-first developers
Suggested direction
Any of:
- Explicit multi-client live attach (CLI + mobile on the same thread)
- Or a clear “monitor/approve-only” secondary session mode for Remote
- Or document and enforce single-writer rules without hard-failing the phone on live threads (e.g. read-only view + queued approvals)
Related: #32445, #34632, #23011
Additional information
No response
What variant of Codex are you using?
CLI + ChatGPT iOS Remote Control (paired hosts)
What feature / fix would you like?
Support the normal workstation-primary workflow:
Today, Remote Control effectively allows the phone to open completed threads, but fails when the workstation CLI already owns a live / in-progress session.
Why this matters
Almost nobody’s main coding surface is the phone. The realistic loop is:
Claude Code Remote Control (
/rc) matches this model: the local CLI session stays primary; mobile is another window into the same live session.Codex Remote currently behaves more like: “pair a host → operate threads from mobile,” and does not reliably share an already-attached live CLI session with iOS.
What happens today (observed)
On the failing live session, iOS shows:
加载消息时出错:Codex 服务器返回了错误。(“Error loading messages: Codex server returned an error.”)
此任务无法重新连接(“This task cannot reconnect”)
So the phone can act as a history viewer for finished threads, but cannot attach to the live session the CLI already owns.
Expected behavior
resume, and does not create divergent continuationsActual behavior
Suggested direction
Any of:
Related: #32445, #34632, #23011
Additional information
No response