Codex Remote can start overlapping continuations in same chat/thread after desktop/mobile reconnect

Summary

After connecting a remote devbox to Codex Remote from the desktop app and then making it available on mobile, reopening/sending messages into an existing long-running Codex chat appeared to start a second continuation of the same chat goal instead of cleanly attaching to the active continuation.

This issue was written by a Codex sidecar agent on behalf of the logged-in GitHub user divinequest, based on local Codex logs and tmux/remote job state observed on the affected devbox.

Environment

• Product: Codex TUI + Codex Remote via desktop app and mobile app
• Codex CLI version observed in session metadata: 0.133.0
• The affected chat/thread was a long-running goal with background tool calls and remote tmux jobs.
• The issue occurred in a single repo/workdir on a single branch; no separate checkout/worktree was created by the app.

What Happened

The user connected an existing devbox to Codex Remote in the desktop app, then enabled it for mobile. After opening what appeared to be the same existing Codex chat from the app/mobile and sending a message, Codex began behaving as though there were two agents working on the same objective.

The visible symptom was that one continuation reported another remote tmux job had appeared unexpectedly. Inspection showed that the "other" job had actually been launched by a different overlapping continuation of the same Codex chat/thread.

Evidence From Logs

The local logs did not show two separate repo checkouts or two independent visible TUI panes for the affected work. They showed:

• one Codex chat/thread id
• one local TUI/tmux pane
• the same working directory
• the same git branch
• multiple overlapping turn ids active inside that same chat/thread

During the overlap:

1. One continuation selected one candidate path and launched a remote tmux eval job.
2. Another continuation, in the same Codex chat/thread, continued a different candidate path and launched a second remote tmux eval job.
3. Each continuation interpreted the other remote job as unexpected or unattributed and tried to manage/kill it.
4. This caused wasted remote work and made the agent's state unreliable.

Later, the UI also showed a warning along the lines of:

chat branch reflects the active branch when last used; sending a message will ...

I do not have the exact full wording, but it appeared while reconnecting to the chat from the app.

Expected Behavior

When opening an existing active remote Codex chat from desktop/mobile:

• the client should attach to the active turn/continuation if one is still running, or
• clearly block sending a new message until the active turn is stopped, or
• explicitly fork into a new chat/session with a clear warning that this will create a separate continuation.

It should not silently start a second overlapping continuation of the same chat goal that can issue tools and mutate external state concurrently.

Actual Behavior

The same chat/thread appeared to get multiple overlapping continuations. Both could issue tool calls and launch/kill remote tmux jobs, while each believed it owned the current state.

This is especially risky for Codex Remote workflows because tool calls may control expensive or stateful external resources such as GPU pods, eval jobs, cloud instances, or deployment processes.

Impact

• Duplicate remote jobs were launched.
• One continuation killed or interfered with jobs launched by the other.
• The agent's mental model of current remote state became unreliable.
• The user had to manually stop the Codex agent from the app and use a separate inspection session to inventory the true local/remote state.

Suggested Safeguards

• Show a strong warning if a chat already has an active turn/background terminal and a second client attempts to send a message.
• Require explicit "stop current run" or "fork new session" before accepting the message.
• Include active turn/tool-call status in the remote UI.
• If branch context changed, explain whether sending will resume, fork, or create a new turn in the same thread.
• Prevent multiple concurrent tool-owning turns in the same thread unless explicitly opted into.

Notes

I can provide more sanitized log snippets if useful. I avoided attaching raw logs because the workspace includes private paths and operational details.