ChatGPT mobile does not show Codex App SSH remote projects/sessions, while Mac host can
Open 💬 4 comments Opened May 27, 2026 by hezhenfan
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
What version of the Codex App are you using (From “About Codex” dialog)?
0.133.0-alpha.1
What subscription do you have?
pro
What platform is your computer?
_No response_
What issue are you seeing?
Mac local Codex sessions are visible on ChatGPT mobile.
Mac Codex App SSH remote sessions on ECS are not visible on mobile.
Mac Codex App can open and use the ECS remote project normally.
ECS starts:
codex app-server --listen unix://
codex app-server proxy
ECS codex version: 0.134.0
Mac bundled codex: 0.133.0-alpha.1
ECS ~/.codex/state_5.sqlite contains the newly created remote threads.
Old Cursor/Codex app-server processes were cleaned; issue still reproduces.
What steps can reproduce the bug?
- On macOS, install the latest Codex App and enable mobile remote control from Settings > Connections.
- Pair the macOS Codex App host with ChatGPT mobile by scanning the QR code.
- Verify that ChatGPT mobile can see local projects/sessions from the macOS Codex App.
- Configure a generic SSH host entry in
~/.ssh/config. - On the remote Linux host, install and log in to Codex CLI.
- From the macOS Codex App, open a project on the remote Linux host over SSH.
- Start a new session in that SSH remote project, for example ask Codex to run a simple shell command or read a generic file.
- On the remote Linux host, confirm that the Codex App started the remote app-server/proxy.
- On the remote Linux host, confirm that the new remote session exists in the Codex state database.
- Open ChatGPT mobile > Codex and select the paired macOS host.
- Observe that local sessions from the macOS host are visible, but the SSH remote project/session created above is not shown.
What is the expected behavior?
_No response_
Additional information
_No response_
4 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I can reproduce what looks like the same issue, with one extra comparison point that may help narrow it down.
Setup:
0.133.0remoteControl/status/changedasconnectedvscode/ originatorCodex DesktopObserved behavior:
thread/listreturns all expectedvscodesessions, including sessions that do not show up in the Android ChatGPT mobile Codex session list.Local evidence:
~/.codex/state_5.sqlitehas the missing thread rows withsource='vscode',archived=0, validcwd, valid rollout paths, and normal metadata.~/.codex/session_index.jsonlalso includes at least one missing session, so this is not simply a missing local index entry.thread/listover the Unix socket returns the missing session.thread/archivefollowed bythread/unarchiveon a missing session succeeds locally, emitsthread/archivedandthread/unarchived, and updatesupdated_at, but the session still does not appear in Android mobile.thread/resumewithclientInfo.name = "codex_chatgpt_android_remote"also succeeds locally and logs an app-server request with that client name, but still does not make the session appear in Android mobile.This makes it look like Android mobile is not rendering the remote host's full app-server
thread/list. It seems to depend on a separate mobile/WHAM task registry or session index, and SSH/remote sessions that exist locally and are visible to desktop clients are not consistently being registered there.Happy to provide sanitized log snippets if useful.
The comparison in archeon-p's comment is the useful split here: remote app-server
thread/listcan be correct while Android mobile still omits the session.I would separate the receipt chain into three independently inspectable edges:
thread_id,source,cwd, rollout/session artifact, archived statethread_idThen each SSH remote session can end in one of a few explicit states:
remote_thread_existsdesktop_can_resumemobile_indexedmobile_registry_missingproject_mapping_missinghost_pairing_staleThat avoids treating "remote app-server has the thread" as proof that mobile can see or continue it.
This is the same acceptance boundary Faryo uses for phone/browser control over host tmux sessions: the mobile surface is not the source of truth; it has to prove it is attached to the intended host-side live session.
https://github.com/Snailflyer/faryo/releases/download/v1.0.7/faryo-public-redacted-same-session-handoff-walkthrough-20260528-0120.gif
same problem