What version of Codex CLI is running?
codex-cli 0.144.4
What subscription do you have?
ChatGPT Pro
Which model were you using?
GPT-5.6 Sol. The symptom appears to be client/session synchronization rather
than model-dependent.
What platform is your computer?
macOS 26.5.2 on Apple Silicon
What terminal emulator and version are you using?
iTerm2 3.6.11 with tmux control mode (tmux -CC)
What issue are you seeing?
When an existing local Codex CLI session is continued from the ChatGPT iOS
Remote feature, the remotely submitted user message and Codex response are
saved to the same thread but are not rendered in the already-open terminal
TUI.
The remote turn appears correctly in the iOS app. In the ChatGPT desktop app,
it also appears in the regular ChatGPT conversation view, but it does not
appear in the Codex part of the desktop app or in the already-open terminal
TUI. Local inspection also confirms that:
- the thread retains the same session ID and
source=cli metadata;
- the local rollout JSONL contains the remote user message and response; and
- a later terminal turn receives the remote exchange in its model context.
The problem is therefore the active TUI view, not lost conversation data or a
forked thread. Quitting the TUI and explicitly resuming the same session ID
reloads the complete transcript.
For comparison, Claude Code Remote Control behaves as expected in the same
kind of workflow: messages sent from mobile appear in the live terminal
session, so returning to the terminal does not require quitting and resuming
the conversation. That live-session continuity is the behavior I expected
from Codex Remote as well.
Around the remote activity, iTerm2 also displayed this warning:
A control sequence attempted to clear scrollback history. Allow this in the
future?
I did not grant permanent permission. I do not know whether that control
sequence is part of the failed refresh or merely coincidental.
What steps can reproduce the bug?
- Start an interactive Codex CLI session in iTerm2 under tmux control mode.
- Configure ChatGPT Remote for that Mac.
- In the ChatGPT iOS app, open Remote and select the existing CLI-originated
chat rather than starting a new chat.
- Send a follow-up message and wait for the response.
- Confirm that the new turn appears in iOS and in the regular ChatGPT
conversation view of the desktop app.
- Confirm that the Codex part of the desktop app and the already-open terminal
TUI still omit the remote message and response.
- Quit and run
codex resume <session-id>; the complete transcript then
appears.
What is the expected behavior?
An active TUI should render messages and responses appended to its thread
through ChatGPT Remote. If live rendering is not possible, it should visibly
indicate that remote activity occurred and offer a reload action without
requiring the user to quit and resume the session.
Additional information
This appears distinct from #18860, which concerned a remote TUI websocket
disconnect under backpressure. This reproduction uses a normal local CLI TUI
continued through the official ChatGPT Remote feature; the backend thread and
subsequent CLI turns remain healthy.
No session transcript or private project information is attached. I can
provide sanitized metadata if maintainers identify specific fields that would
help diagnose the event-subscription or redraw path.
What version of Codex CLI is running?
codex-cli 0.144.4What subscription do you have?
ChatGPT Pro
Which model were you using?
GPT-5.6 Sol. The symptom appears to be client/session synchronization rather
than model-dependent.
What platform is your computer?
macOS 26.5.2 on Apple Silicon
What terminal emulator and version are you using?
iTerm2 3.6.11 with tmux control mode (
tmux -CC)What issue are you seeing?
When an existing local Codex CLI session is continued from the ChatGPT iOS
Remote feature, the remotely submitted user message and Codex response are
saved to the same thread but are not rendered in the already-open terminal
TUI.
The remote turn appears correctly in the iOS app. In the ChatGPT desktop app,
it also appears in the regular ChatGPT conversation view, but it does not
appear in the Codex part of the desktop app or in the already-open terminal
TUI. Local inspection also confirms that:
source=climetadata;The problem is therefore the active TUI view, not lost conversation data or a
forked thread. Quitting the TUI and explicitly resuming the same session ID
reloads the complete transcript.
For comparison, Claude Code Remote Control behaves as expected in the same
kind of workflow: messages sent from mobile appear in the live terminal
session, so returning to the terminal does not require quitting and resuming
the conversation. That live-session continuity is the behavior I expected
from Codex Remote as well.
Around the remote activity, iTerm2 also displayed this warning:
I did not grant permanent permission. I do not know whether that control
sequence is part of the failed refresh or merely coincidental.
What steps can reproduce the bug?
chat rather than starting a new chat.
conversation view of the desktop app.
TUI still omit the remote message and response.
codex resume <session-id>; the complete transcript thenappears.
What is the expected behavior?
An active TUI should render messages and responses appended to its thread
through ChatGPT Remote. If live rendering is not possible, it should visibly
indicate that remote activity occurred and offer a reload action without
requiring the user to quit and resume the session.
Additional information
This appears distinct from #18860, which concerned a remote TUI websocket
disconnect under backpressure. This reproduction uses a normal local CLI TUI
continued through the official ChatGPT Remote feature; the backend thread and
subsequent CLI turns remain healthy.
No session transcript or private project information is attached. I can
provide sanitized metadata if maintainers identify specific fields that would
help diagnose the event-subscription or redraw path.