›_ Codex Issues
Codex Issues / #23062

Mobile Remote Control does not discover SSH remote project threads despite documented remote development environment support

Open 💬 7 comments Opened May 16, 2026 by mikhail-yaskou
💡 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)?

Codex Version 26.513.31313 (2867), Mobile ChatGPT App Version 1.2026.125

What subscription do you have?

Pro

What platform is your computer?

Darwin 24.6.0 x86_64 i386, IOS 26.4.2

What issue are you seeing?

Codex Desktop can connect to a project that lives in an SSH remote environment. The documentation says that, in this setup, a phone connects to the Codex App host while Codex works in the remote environment:

### A remote development environment Use an SSH host or managed devbox when the project already lives in a remote environment. Connect the Codex App host to that environment first; your phone still connects to the Codex App host, and Codex works in the remote environment with its dependencies, security policies, and compute resources. For SSH setup details, see connect to an SSH host.

Source: https://developers.openai.com/codex/remote-connections

In practice, when an SSH remote project is visible and usable in Codex Desktop, Codex mobile Remote Control does not show that remote project or its threads. The mobile Projects list appears to be derived from the Desktop host's local thread/list response instead.

The observed mobile request is a plain local thread/list:

{
  "method": "thread/list",
  "params": {
    "archived": false,
    "limit": 200,
    "sortKey": "updated_at",
    "sourceKinds": []
  }
}

The response contains local Desktop-host threads with local cwd values. I did not observe a request that lists configured remote projects or proxies thread/list to the SSH remote app-server / remote Codex state.

What steps can reproduce the bug?

  1. Install Codex Desktop.
  2. Configure an SSH remote host or managed remote development environment.
  3. Connect a project that lives in that remote environment.
  4. Verify that the remote project appears and works in Codex Desktop.
  5. Start or resume one or more threads in that remote project.
  6. Pair Codex mobile / ChatGPT mobile with the Desktop host using Remote Control.
  7. Open the mobile sidebar and inspect Projects.

What is the expected behavior?

When Codex Desktop has an SSH remote project connected and working:

  1. Mobile Remote Control should show that remote project.
  2. Mobile should list the remote project's threads.
  3. Opening a remote thread from mobile should resume it successfully.
  4. Subsequent turns, file operations, approvals, and shell execution should run in the documented remote environment.

Instead, the SSH remote project and its threads are missing. Mobile appears to show projects inferred from local Desktop-host thread history.

Additional information

I checked the public openai/codex app-server code to understand whether this is only a sidebar issue or a deeper remote-thread lifecycle issue.

My reading is that the current public app-server contract does not seem to carry enough remote-project identity through the thread lifecycle. A mobile client can receive a Thread from thread/list, but that object does not appear to say which SSH host / remote project / remote environment owns it. Later calls such as thread/resume and turn/start also appear to address threads only by threadId inside the current app-server process.

That is the important part: if mobile gets a remote-looking thread row from the Desktop host, the Desktop host still needs a way to resolve that thread back to the SSH remote state. I could not find that bridge in the public code.

Supporting details:

  • ThreadListParams and Thread do not appear to carry environmentId, hostId, remotePath, or another remote-project identity.
  • thread/resume appears to load history through the current app-server's ThreadStore, not through a remote project/thread registry.
  • turn/start appears to address an already-loaded thread in the current app-server's thread_manager, so a remote thread must first be resolved into the correct remote execution context.

So this may require more than adding remote-looking rows to thread/list; remote thread resume also needs to resolve the backing remote state and associate it with the correct remote execution environment.

This is an important Remote Control workflow. SSH remote projects and managed devboxes let users run agents inside safer containers or remote development environments while controlling them from mobile through the paired Desktop app. That is the documented promise: the phone connects to the Codex App host, but Codex works in the remote environment with that environment's dependencies, security policies, and compute resources.

Related but different issues:

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 2 months ago

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

  • #22438
  • #22762
  • #22806

Powered by Codex Action

mikhail-yaskou · 2 months ago
Potential duplicates detected. Please review them and close your issue if it is a duplicate. https://github.com/openai/codex/issues/22438 https://github.com/openai/codex/issues/22762 https://github.com/openai/codex/issues/22806

This does not appear to be a duplicate: only #22806 looks related at the root-cause level, but it covers sidebar sync/order, while this issue specifically focuses on SSH remote projects and their threads not being discovered or usable from mobile Remote Control at all.

panzeyu2013 · 2 months ago

I’m facing the same issue here. I found a workaround:

  1. Archive the session.
  2. Unarchive the session.

After that, the thread appears in the mobile app.

JackeyCloud · 2 months ago

我也遇到了同样的问题。但是上面的老哥解决方法是把会话存档，然后再取消。之后这个项目依旧还是没有出现在我的手机上。

我遇到这个问题，尝试了非常多的方法，甚至让 Codex 自己去修复，但是最终还是无功而返

Snailflyer · 2 months ago

This does look deeper than a sidebar sync issue. For mobile to safely resume an SSH remote project, the remote-project identity has to survive across thread/list, thread/resume, and turn/start; otherwise the phone can only see local host rows, or worse, resume a thread against the wrong execution owner.

The archive/unarchive workaround is a useful clue, but it sounds like it may only refresh one registry layer. The core contract still needs to say which process owns the thread: Desktop host, SSH remote app-server, managed devbox, etc. Without that owner identity, approvals and shell/file operations from mobile cannot be safely routed.

A narrower model I have been building is Faryo: https://github.com/Snailflyer/faryo

It is not a fix for Codex Desktop remote projects. The design is different: run Codex/Claude/shell directly inside tmux on the Linux/SSH host that owns the work, then let phone/desktop browsers act as a lightweight workbench for output, short input, approve/interrupt, and handoff against that same live process. So it may be relevant if your desired model is "the SSH environment is the real owner; phone just attaches to that owner," rather than "phone talks to Desktop, Desktop proxies to SSH."

hans43564334-pixel · 1 month ago

I can reproduce this on newer builds, and my local evidence matches the suspected ownership/routing gap described above.

Environment

  • Codex App for macOS: 26.519.41501 / bundle 3044
  • Local Codex CLI/runtime on the Mac host: codex-cli 0.133.0
  • Remote SSH host Codex CLI/runtime: codex-cli 0.133.0
  • Mobile client: ChatGPT Android app with Codex Remote Control
  • Same ChatGPT account/workspace on Mac and Android
  • Phone is paired to the Mac host successfully; the Mac host appears online in mobile

What works

From the Mac host, the SSH remote setup is valid:

ssh <ssh-alias> 'hostname; command -v codex; codex --version; codex app-server --help'

returns a real remote hostname, a remote codex binary on PATH, codex-cli 0.133.0, and valid codex app-server help output.

The Mac Codex App also has the SSH host and remote project registered locally. Sanitized local state contains:

{
  "selected-remote-host-id": "remote-ssh-discovered:<ssh-alias>",
  "remote-connection-auto-connect-by-host-id": {
    "remote-ssh-discovered:<ssh-alias>": true
  },
  "codex-managed-remote-connections": [
    {
      "hostId": "remote-ssh-discovered:<ssh-alias>",
      "displayName": "<ssh-alias>",
      "source": "discovered",
      "alias": "<ssh-alias>"
    }
  ],
  "remote-projects": [
    {
      "hostId": "remote-ssh-discovered:<ssh-alias>",
      "remotePath": "/remote/project/path",
      "label": "<remote-project>"
    }
  ],
  "codex-mobile-has-connected-device": true
}

The Mac host also has a Remote Control enrollment for mobile, while the SSH remote host itself does not have a mobile enrollment. So the phone is controlling the Mac host, not directly enrolling the Linux/SSH host.

Repro

  1. On the Mac Codex App, open an SSH remote project backed by remote-ssh-discovered:<ssh-alias>.
  2. Start a fresh thread in that remote project.
  3. Ask a simple diagnostic prompt such as confirm hostname and pwd.
  4. Confirm the thread runs in the SSH remote environment.
  5. Open ChatGPT Android > Codex > the connected Mac host.
  6. Inspect the Projects / recent thread list.

Actual behavior

Mobile shows only Mac-local projects and Mac-local recent threads. The SSH remote project and the new SSH remote thread do not appear, even though the same remote project/thread is visible and usable from the Mac Codex App.

In my Android screenshot, the connected host is online, but the project list only includes local Mac projects such as local workspace folders. The freshly-created SSH remote thread is absent.

Additional local evidence

After creating the SSH remote thread from the Mac Codex App, I checked both state databases.

On the Mac host, ~/.codex/state_5.sqlite does not contain the new remote thread under the remote cwd. Its recent rows are Mac-local cwd values.

On the SSH remote host, ~/.codex/state_5.sqlite does contain the new thread:

source = vscode
cwd    = /remote/project/path
title  = confirm hostname and pwd

So the new remote thread is real and durable, but it is durable in the SSH remote host's Codex state, not in the Mac host's local thread DB that the mobile project/thread list appears to be reading from.

This supports the earlier hypothesis that mobile is listing/resuming against the connected Mac host's local thread/project state and does not yet have enough remote-project ownership identity to discover and route SSH remote threads through the Mac host to the correct remote app-server.

Expected behavior

When a phone is paired to a Mac Codex App host, and that Mac host has working SSH remote projects, mobile should either:

  1. list the SSH remote projects/threads and preserve enough identity to route thread/resume / turn/start back to the correct remote app-server, or
  2. explicitly label this as unsupported in the mobile UI/docs so users do not interpret it as an SSH setup failure.

The important part is that simply adding remote-looking rows to the mobile list would not be enough unless the subsequent lifecycle methods carry the owning remote context (hostId, remotePath, environmentId, or equivalent).

danielcrabtree · 18 days ago

I'm having the same problem. Seems to be a limitation of the mobile app not listing the remote projects. But in addition, I tried the "archive session" / "unarchive session" suggestion and while the archive part worked, I haven't been able to find anyway to "unarchive" the remote session. When I go to "settings / archived chats", I can choose from All, Local, or Cloud chats, but none of those options include the remote project chats - specifically the ones from the SSH remote. So there seems to be similar problems / limitations with remotes within the desktop app too.