Allow attaching the Codex terminal TUI to an existing Remote Control chat #32445

Activity

1. github-actions

   added

   enhancementNew feature or requestNew feature or request

   CLIIssues related to the Codex CLIIssues related to the Codex CLI

   TUIIssues related to the terminal user interface: text input, menus and dialogs, and terminal displayIssues related to the terminal user interface: text input, menus and dialogs, and terminal display

   remote

   sessionIssues involving session (thread) management, resuming, forking, naming, archivingIssues involving session (thread) management, resuming, forking, naming, archiving

   on Jul 11, 2026
2. liyoungc commented on Jul 14, 2026

   

   liyoungc

   on Jul 14, 2026

   More actions

   Confirmed on WSL2/Linux with codex-cli 0.144.4: codex remote-control --help exposes only start, stop, and pair—no attach or resume command.

   I would like to keep the existing local CLI TUI visible and usable on the host, then use ChatGPT mobile Remote to inspect the same live thread, send follow-ups, and handle approval requests. Returning to the terminal should continue that exact thread rather than create a separate session or competing continuation.

   A supported host-mediated pairing/control path for an existing CLI TUI thread would cover this workflow. It should work for WSL/Linux hosts as well as the desktop-app flow, without exposing an app-server WebSocket directly to the LAN or Internet.
3. raymondtreehome commented on Aug 14, 2026

   

   raymondtreehome

   on Aug 14, 2026 – with ChatGPT Codex Connector

   More actions

   I found a working path for this on macOS with codex-cli 0.147.0. It does not use a remote-control attach subcommand; instead, the top-level --remote option can be combined with resume.

   Test setup:

   codex app-server --remote-control --listen unix://...

   Then, from a separate terminal/TUI:

   codex --remote unix://<canonical-app-server-socket> resume <THREAD_ID>

   I tested this against an existing Codex thread that had been created from ChatGPT on iPhone.

   Observed behavior:

   • the terminal TUI rendered the existing conversation history;
   • a marker turn sent from the TUI landed in the same thread;
   • no fork or replacement thread was created;
   • the new turn was visible again in the same conversation on iPhone;
   • the canonical app-server remained the thread writer throughout the test.

   So, at least on 0.147.0, the architecture can effectively be:

   canonical app-server
           |
        same thread
      /     |      \
   iPhone   TUI   external client
   

   One important distinction: this is not the same as bare:

   codex resume <THREAD_ID>

   In my testing, the safe path was specifically codex --remote ... resume, where the TUI behaves as a client of the already-running canonical app-server rather than starting an independent local continuation.

   I have only verified this on my own macOS environment with 0.147.0, so I would treat it as observed behavior rather than a documented stability guarantee.

   AI assistance disclosure: The investigation and test design were largely AI-guided by ChatGPT (OpenAI) and Claude Code (Anthropic). Claude Code executed much of the terminal-side diagnostic work; I provided the environment and personally verified the phone-side behavior.