Codex Desktop SSH restart disables mobile remote control by restarting app-server without --remote-control
What version of the Codex App are you using (From "About Codex" dialog)?
Codex App 26.513.31313 (2867)
Remote host Codex CLI/App Server:
codex-cli 0.132.0
What subscription do you have?
ChatGPT Pro, 5x plan. Signed in on both Codex Desktop and the ChatGPT mobile app.
What platform is your computer?
Local Codex Desktop host:
Darwin 25.4.0 arm64 arm
Remote SSH host:
Linux 5.15.120.bsk.3-amd64 x86_64 unknown
What issue are you seeing?
I am using Codex Desktop on macOS with an SSH remote host, and I want the ChatGPT mobile app to connect to/control the remote host.
The mobile remote-control path works if I manually start the new remote-control daemon entrypoint on the remote host:
~/.codex/packages/standalone/current/codex remote-control start
After that, the remote host has the expected process:
codex app-server --remote-control --listen unix://
codex app-server daemon pid-update-loop
The ChatGPT Android app can then reach the remote app-server. The remote app-server logs show requests from:
app_server.client_name="codex_chatgpt_android_remote"
However, two Codex Desktop UI actions appear to use stale/non-remote-control paths:
- In Settings -> Connections -> SSH -> remote host details, the
Available from signed-in devicestoggle turns on briefly and then immediately turns itself off. - If I use the Codex Desktop UI to restart Codex on the SSH remote host, the mobile app can no longer connect. After the restart, the remote host is running a plain app-server process without
--remote-control:
codex app-server --listen unix://
At the same time, the remote daemon settings still say remote control is enabled:
{
"remoteControlEnabled": true
}
The remote config also contains:
[features]
remote_control = true
But codex features list on the remote host reports:
remote_control removed false
This makes the UI state confusing: the actual remote-control daemon can work, but the Desktop UI toggle still reads as disabled, and the Desktop restart action replaces the working remote-control app-server with a non-remote-control app-server.
What steps can reproduce the bug?
- Use Codex Desktop on macOS and add an SSH remote host.
- On the remote host, use Codex CLI/App Server 0.132.0.
- Start remote control manually on the remote host:
``sh``
~/.codex/packages/standalone/current/codex remote-control start
- Verify the remote host is running:
``text``
codex app-server --remote-control --listen unix://
- Verify the ChatGPT mobile app can connect to the remote host.
- Open Codex Desktop Settings -> Connections -> SSH -> remote host details.
- Try to enable
Available from signed-in devices. - Observe that the toggle immediately turns itself back off.
- Use Codex Desktop's UI action to restart Codex on the SSH remote host.
- Check the remote host processes again.
Actual result after Desktop restart:
codex app-server --listen unix://
Expected process would preserve remote-control mode:
codex app-server --remote-control --listen unix://
What is the expected behavior?
- If the new supported path is
codex remote-control start, Codex Desktop's SSH remote restart action should preserve/restart the remote host in remote-control mode when remote control is enabled. - The
Available from signed-in devicestoggle should reflect the daemon/settings state that actually controls mobile remote access, instead of reading a removed feature flag as disabled. - The UI should not report the remote host as unavailable from signed-in devices when mobile remote-control is actually enabled and working.
Additional information
This may be related to the transition from the old [features].remote_control flag to the newer codex remote-control start / app-server daemon flow.
Relevant observed facts:
codex features list:
remote_control removed false
~/.codex/app-server-daemon/settings.json:
{
"remoteControlEnabled": true
}
After manual codex remote-control start, mobile remote control works. After Codex Desktop remote restart, the remote-control flag disappears from the app-server process and mobile remote control stops working.
I am omitting the concrete SSH hostname/IP/account/server IDs from this report.
This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗