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?

  1. On macOS, install the latest Codex App and enable mobile remote control from Settings > Connections.
  2. Pair the macOS Codex App host with ChatGPT mobile by scanning the QR code.
  3. Verify that ChatGPT mobile can see local projects/sessions from the macOS Codex App.
  4. Configure a generic SSH host entry in ~/.ssh/config.
  5. On the remote Linux host, install and log in to Codex CLI.
  6. From the macOS Codex App, open a project on the remote Linux host over SSH.
  7. Start a new session in that SSH remote project, for example ask Codex to run a simple shell command or read a generic file.
  8. On the remote Linux host, confirm that the Codex App started the remote app-server/proxy.
  9. On the remote Linux host, confirm that the new remote session exists in the Codex state database.
  10. Open ChatGPT mobile > Codex and select the paired macOS host.
  11. 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_

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #23527
  • #24212
  • #24271

Powered by Codex Action

archeon-p · 3 months ago

I can reproduce what looks like the same issue, with one extra comparison point that may help narrow it down.

Setup:

  • Remote host: Ubuntu 24.04 x86_64, Codex CLI/app-server 0.133.0
  • Remote app-server is connected to remote control and reports remoteControl/status/changed as connected
  • Session source is vscode / originator Codex Desktop
  • ChatGPT Android remote client is in use for mobile access
  • A separate Windows laptop Codex App can see the current remote session correctly

Observed behavior:

  • The remote Linux app-server thread/list returns all expected vscode sessions, including sessions that do not show up in the Android ChatGPT mobile Codex session list.
  • The same current session is visible from the Windows Codex App, so the session metadata and remote host app-server state appear healthy.
  • Android ChatGPT mobile only shows a subset of sessions.

Local evidence:

  • ~/.codex/state_5.sqlite has the missing thread rows with source='vscode', archived=0, valid cwd, valid rollout paths, and normal metadata.
  • ~/.codex/session_index.jsonl also includes at least one missing session, so this is not simply a missing local index entry.
  • Direct app-server thread/list over the Unix socket returns the missing session.
  • Calling thread/archive followed by thread/unarchive on a missing session succeeds locally, emits thread/archived and thread/unarchived, and updates updated_at, but the session still does not appear in Android mobile.
  • Calling thread/resume with clientInfo.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.

Snailflyer · 2 months ago

The comparison in archeon-p's comment is the useful split here: remote app-server thread/list can be correct while Android mobile still omits the session.

I would separate the receipt chain into three independently inspectable edges:

  • remote host truth: app-server has thread_id, source, cwd, rollout/session artifact, archived state
  • desktop/client truth: paired desktop host can list and resume that remote thread
  • mobile registry truth: paired mobile host/project list includes the same thread_id

Then each SSH remote session can end in one of a few explicit states:

  • remote_thread_exists
  • desktop_can_resume
  • mobile_indexed
  • mobile_registry_missing
  • project_mapping_missing
  • host_pairing_stale

That 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

huanhuan6666 · 2 months ago

same problem