codex - 💡(How to fix) Fix Mobile Remote Control cannot connect to Linux SSH remote project on Codex 0.133+/0.134, works after downgrading remote host to 0.130.0

What version of the Codex App are you using?

Codex App for macOS: 26.519.81530 (build 3178)

Desktop bundled CLI:

codex-cli 0.133.0

Desktop app-server:

appServerVersion: 0.135.0
managedCodexVersion: 0.135.0
cliVersion: 0.133.0

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Desktop host:

Darwin 25.5.0 arm64 arm

Linux SSH remote host that fails on newer Codex versions:

Linux 6.17.0-29-generic x86_64 x86_64

WSL SSH remote host that works:

Linux 6.6.87.2-microsoft-standard-WSL2 x86_64 x86_64

What issue are you seeing?

ChatGPT mobile Remote Control can connect to my paired macOS Codex Desktop host, and it can control SSH remote projects on WSL. However, it cannot connect to an SSH remote project on a Linux physical host when that remote host runs Codex CLI/app-server 0.133.0 or 0.134.0.

On mobile, selecting the Linux SSH remote project shows "Unable to connect".

The same Linux remote project works from Codex Desktop. SSH connectivity is healthy, the remote project path exists, and the remote app-server/proxy processes are running.

Downgrading only the remote Linux host to @openai/[email protected] immediately restores mobile Remote Control for the same host, same SSH route, same macOS Desktop host, same mobile pairing, and same remote project path.

This looks like a regression in the SSH remote app-server/proxy path used by mobile Remote Control after 0.130.0.

What steps can reproduce the bug?

1. Pair ChatGPT mobile with Codex App for macOS.

2. Add two SSH remote hosts/projects to the macOS Codex App:

   • WSL2 remote host running @openai/[email protected]
   • Linux physical remote host running @openai/[email protected] or 0.134.0

3. Confirm both SSH remote projects work from Codex Desktop.

4. Confirm the Linux host has Remote Control enabled:

   remote_control = true

5. Confirm the Linux remote app-server/proxy processes are running.

6. Open ChatGPT mobile -> Codex Remote Control.

7. Select the paired macOS Codex Desktop host.

8. Select the Linux SSH remote project.

Observed:

Unable to connect

1. Downgrade only the Linux remote host:

   npm install -g @openai/[email protected]
   pkill -TERM -f 'codex.*app-server'

2. Let Codex Desktop/mobile reconnect to the same Linux remote project.

Observed after downgrade:

Mobile Remote Control works again.

What is the expected behavior?

Mobile Remote Control should be able to connect to SSH remote projects through the paired macOS Codex Desktop host when the same remote project already works in Codex Desktop.

The mobile connection should not fail only because the remote Linux host is running 0.133.0 or 0.134.0, especially when the same setup works after downgrading the remote host to 0.130.0.

Additional information

Diagnostics already checked:

• Mobile pairing is not globally broken: WSL SSH remote projects still work from mobile.
• The macOS Codex Desktop host is online and controllable from mobile.
• The Linux remote host is reachable over SSH.
• The Linux remote project works from Codex Desktop.
• The Linux remote project path exists.
• Recreating the Linux remote project did not fix the issue.
• Switching the Linux remote project path to an ASCII-only path did not fix the issue.
• Restarting the macOS app-server did not fix the issue.
• Downgrading the Linux remote host from 0.133.0 / 0.134.0 to 0.130.0 did fix the issue.

Version evidence:

Failing:
Linux remote host @openai/[email protected] -> mobile unable to connect
Linux remote host @openai/[email protected] -> mobile unable to connect

Working:
Linux remote host @openai/[email protected] -> mobile works

Current working Linux remote state:

codex-cli 0.130.0
@openai/[email protected]
remote_control = true
remote project path: /home/atk/codex-workspace

Related issues:

• #23527
• #23062
• #23403

Those issues appear related to mobile Remote Control with SSH remote projects, but this report is specifically about a version regression on the remote Linux app-server/proxy side: 0.130.0 works while 0.133.0 and 0.134.0 fail for the same Linux SSH remote project.