Skip to content

Codex Desktop SSH restart disables mobile remote control by restarting app-server without --remote-control #23699

Open
Open
Codex Desktop SSH restart disables mobile remote control by restarting app-server without --remote-control#23699
Labels
appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbugSomething isn't workingremote

Description

@hmmm42
hmmm42
opened on May 20, 2026

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:

  1. In Settings -> Connections -> SSH -> remote host details, the Available from signed-in devices toggle turns on briefly and then immediately turns itself off.
  2. 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?

  1. Use Codex Desktop on macOS and add an SSH remote host.

  2. On the remote host, use Codex CLI/App Server 0.132.0.

  3. Start remote control manually on the remote host:

    ~/.codex/packages/standalone/current/codex remote-control start

  4. Verify the remote host is running:

    codex app-server --remote-control --listen unix://

  5. Verify the ChatGPT mobile app can connect to the remote host.

  6. Open Codex Desktop Settings -> Connections -> SSH -> remote host details.

  7. Try to enable Available from signed-in devices.

  8. Observe that the toggle immediately turns itself back off.

  9. Use Codex Desktop's UI action to restart Codex on the SSH remote host.

  10. 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 devices toggle 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.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    app-serverIssues involving app server protocol or interfaces
    remote
    on May 20, 2026

  2. github-actions commented on May 20, 2026

    @github-actions
    github-actionsBot
    on May 20, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. Keesan12 commented on May 20, 2026

    @Keesan12
    Keesan12
    on May 20, 2026

    This feels like a control-plane contract bug more than an SSH bug.

    If remote control depends on --remote-control, the restart path should either preserve that flag from the live session config or refuse a restart that would downgrade capabilities. Otherwise the app-server comes back "healthy" but with a different authority boundary than the user actually started with.

    A useful fix pattern here is to persist the restart receipt alongside the session: previous flags, new flags, and any capability delta. That makes this kind of regression obvious instead of looking like mobile control randomly died.

  4. Keesan12 commented on May 20, 2026

    @Keesan12
    Keesan12
    on May 20, 2026

    Yes, and I would make that capability delta machine-readable rather than only human-visible.\n\nSomething like a restart receipt with:\n\n- previous launch flags\n- new launch flags\n- dropped capabilities\n- reason for the restart\n- whether the restart was allowed to proceed despite the downgrade\n\nThat gives the UI one honest state transition to show: healthy with preserved capabilities versus healthy but degraded. Right now the problem is not just that remote control breaks, it is that the restart path makes the downgrade look like success.

  5. christophergorexyz commented on Aug 16, 2026

    @christophergorexyz
    christophergorexyz
    on Aug 16, 2026 – with ChatGPT Codex Connector

    AI generation disclosure: This report was drafted with assistance from ChatGPT based on diagnostics I ran and outputs I provided. I reviewed the technical details before posting.

    I believe I'm seeing a current variant of this issue with codex-cli 0.147.0.

    Environment

    Remote host:

    Ubuntu Linux
kernel 6.8.0-124-generic
x86_64
codex-cli 0.147.0

    The machine is a headless Linux host accessed by Codex clients over SSH. I also use ChatGPT on Android to access it via Codex Remote Control.

    Symptoms

    The Android app would remain indefinitely at Pending when attempting to connect to the remote host.

    Interestingly:

    codex remote-control pair

    reported successful pairing.

    However:

    codex remote-control start --json

    failed with:

    Error: app server is running but is not managed by codex app-server daemon

    Existing app-server

    The host had these processes:

    codex -c features.code_mode_host=true app-server --listen unix://
codex app-server proxy

    The first process belonged to an SSH login session. systemctl status <pid> showed:

    session-13919.scope - Session 13919 of User <user>
Active: active (abandoned)

    with the Codex process still inside the session cgroup:

    systemd
└─ codex -c features.code_mode_host=true app-server ...

    The corresponding SSH connection itself had already disconnected.

    I suspect this may be intentional behavior used by Codex clients to allow reconnection to an SSH-hosted app-server rather than simply an accidentally orphaned process.

    Remote-control logs

    The remote-control transport itself initialized without WARN or ERROR entries.

    Relevant sequence:

    starting app-server remote control websocket task
app-server remote control websocket task started
app-server remote control websocket loop started
starting app-server remote control websocket connection cycle
connecting to app-server remote control websocket
reusing persisted remote control enrollment
remote control websocket environment changed status=Connecting
refreshing remote control server token

    It remained in Connecting.

    The persisted enrollment was recognized, so I did not clear authentication, enrollment, or Codex state.

    Recovery

    I terminated the SSH session scope containing:

    codex -c features.code_mode_host=true app-server --listen unix://

    After removing that app-server, the Android client connected successfully without re-pairing, changing authentication, or resetting the remote-control enrollment.

    This gives a fairly clean A/B reproduction:

    SSH code-mode app-server running
    -> Android Remote Control remains Pending
    -> `remote-control start` reports app-server is not daemon-managed

SSH code-mode app-server removed
    -> existing Android Remote Control connection succeeds

    Possible underlying issue

    This looks like an ownership/coexistence problem between the SSH code-mode host and the newer daemon-managed Remote Control path.

    In particular, an SSH client can apparently leave/reuse:

    codex -c features.code_mode_host=true app-server --listen unix://

    while Remote Control expects the active app-server to be managed by codex app-server daemon.

    Ideally an SSH-hosted Codex server and Remote Control would either:

    1. share the daemon-managed app-server,
    2. hand ownership over safely, or
    3. allow the existing SSH app-server to enable Remote Control without requiring it to be destroyed.

    The current behavior makes Remote Control silently appear broken from the Android side (Pending) even though pairing succeeds, while the actionable ownership error is only visible when running codex remote-control start directly on the host.

  6. David-Moss-Better-Outcomes-Asia commented on Oct 17, 2026

    @David-Moss-Better-Outcomes-Asia
    David-Moss-Better-Outcomes-Asia
    on Oct 17, 2026

    same issue

  7. ruizanthony commented on Oct 19, 2026

    @ruizanthony
    ruizanthony
    on Oct 19, 2026

    Additional restart/recovery observation on October 19, 2026, using ChatGPT Android Remote and a Linux x86_64 host with a local 0.163.0-based server build.

    After a scheduled daemon restart for a local Voice prototype, the local control-socket API responded and saved threads were readable, but the user reported that the Android-to-host bridge was unavailable and required a host-side CLI recovery/restart. The restart service itself had completed successfully. The persisted daemon setting was remoteControlEnabled=true.

    After host-side recovery, remoteControl/status/read returned connected, and Android resumed this same saved task. We did not capture the original unavailable process's full launch arguments or a sufficient pre-recovery transport trace, so this does not establish that the remote-control flag was dropped, or prove the same root cause as this issue.

    A local deployment-check improvement now treats local API readiness and Remote Control connectivity as separate conditions: it requires the latter to report connected, re-enables the configured Remote Control mode if needed, and waits for reconnection before reporting deployment success. This is a health/recovery improvement, not a confirmed upstream transport fix.

    A separate missing-tool-output panic was also seen after one recovery in the locally compiled development build; it is being addressed by using production assertion settings rather than treating that debug-build behavior as evidence of the same Remote Control failure. No raw logs, private transcript, host/account identifiers, or credentials are attached.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbugSomething isn't workingremote

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions