codex - 💡(How to fix) Fix CLI remote-control reports connected on macOS but host is not visible in mobile unless Codex.app is running

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Root Cause

This is confusing because the same CLI command works as expected on a Linux host.

Code Example

Darwin 25.5.0 arm64 arm

---

Linux 6.12.57+deb13-amd64 x86_64 unknown

---

codex remote-control --json start

---

{
  "overallStatus": "ok",
  "codexVersion": "0.133.0",
  "checks": {
    "app_server.status": {
      "status": "ok",
      "summary": "background server is running"
    },
    "auth.credentials": {
      "status": "ok",
      "summary": "auth is configured",
      "details": {
        "stored ChatGPT tokens": "true",
        "stored auth mode": "chatgpt"
      }
    },
    "network.provider_reachability": {
      "status": "ok",
      "summary": "active provider endpoints are reachable over HTTP"
    },
    "network.websocket_reachability": {
      "status": "ok",
      "summary": "Responses WebSocket handshake succeeded",
      "details": {
        "handshake result": "HTTP 101 Switching Protocols",
        "supports websockets": "true"
      }
    },
    "runtime.provenance": {
      "status": "ok",
      "summary": "running standalone on macos-aarch64",
      "details": {
        "version": "0.133.0",
        "platform": "macos-aarch64"
      }
    }
  }
}

---

codex remote-control --json start

---

{
  "mode": "daemon",
  "status": "connected",
  "serverName": "Mac-mini",
  "environmentId": "env_e_...",
  "timedOut": false,
  "daemon": {
    "status": "alreadyRunning",
    "backend": "pid",
    "managedCodexVersion": "0.133.0",
    "cliVersion": "0.133.0",
    "appServerVersion": "0.133.0"
  }
}

---

codex app-server daemon pid-update-loop
codex app-server --remote-control --listen unix://

---

/Applications/Codex.app/Contents/MacOS/Codex
/Applications/Codex.app/Contents/Resources/codex app-server --analytics-default-enabled

---

macOS CLI-only remote-control connected -> not visible in mobile
macOS Codex.app running -> visible in mobile
Linux CLI-only remote-control connected -> visible in mobile

---

codex remote-control --json start

---

{
     "status": "connected",
     "timedOut": false
   }

---

codex app-server daemon pid-update-loop
   codex app-server --remote-control --listen unix://

---

open -a Codex

---

codex remote-control --json start

---

app_server_client_name = Codex Desktop
app_server_client_name = Codex Desktop
app_server_client_name = <empty>
RAW_BUFFERClick to expand / collapse

What version of Codex CLI is running?

codex-cli 0.133.0

What subscription do you have?

ChatGPT Pro

Which model were you using?

N/A. This is about codex remote-control start.

What platform is your computer?

Affected macOS host:

Darwin 25.5.0 arm64 arm

Comparison Linux host where CLI-only remote control is visible in mobile:

Linux 6.12.57+deb13-amd64 x86_64 unknown

What terminal emulator and version are you using (if applicable)?

Reproduced from an SSH shell on the macOS host. The command is non-interactive:

codex remote-control --json start

Codex doctor report

Relevant excerpt from codex doctor --json on the macOS host:

{
  "overallStatus": "ok",
  "codexVersion": "0.133.0",
  "checks": {
    "app_server.status": {
      "status": "ok",
      "summary": "background server is running"
    },
    "auth.credentials": {
      "status": "ok",
      "summary": "auth is configured",
      "details": {
        "stored ChatGPT tokens": "true",
        "stored auth mode": "chatgpt"
      }
    },
    "network.provider_reachability": {
      "status": "ok",
      "summary": "active provider endpoints are reachable over HTTP"
    },
    "network.websocket_reachability": {
      "status": "ok",
      "summary": "Responses WebSocket handshake succeeded",
      "details": {
        "handshake result": "HTTP 101 Switching Protocols",
        "supports websockets": "true"
      }
    },
    "runtime.provenance": {
      "status": "ok",
      "summary": "running standalone on macos-aarch64",
      "details": {
        "version": "0.133.0",
        "platform": "macos-aarch64"
      }
    }
  }
}

I can provide the full doctor output if needed.

What issue are you seeing?

On macOS, running the CLI remote-control command reports success and the daemon/app-server processes are running, but the host does not appear in the ChatGPT mobile Codex remote host list.

Command output on macOS:

codex remote-control --json start
{
  "mode": "daemon",
  "status": "connected",
  "serverName": "Mac-mini",
  "environmentId": "env_e_...",
  "timedOut": false,
  "daemon": {
    "status": "alreadyRunning",
    "backend": "pid",
    "managedCodexVersion": "0.133.0",
    "cliVersion": "0.133.0",
    "appServerVersion": "0.133.0"
  }
}

The expected two CLI processes are present:

codex app-server daemon pid-update-loop
codex app-server --remote-control --listen unix://

Network connectivity also appears fine. The macOS CLI app-server has an established TCP connection to the ChatGPT remote-control relay, and codex doctor --json reports websocket reachability as OK.

However, the mobile app still does not show this macOS host.

If I launch /Applications/Codex.app on the same Mac, the host becomes visible in the mobile app. After launching Codex.app, additional processes appear, including:

/Applications/Codex.app/Contents/MacOS/Codex
/Applications/Codex.app/Contents/Resources/codex app-server --analytics-default-enabled

So the difference seems to be:

macOS CLI-only remote-control connected -> not visible in mobile
macOS Codex.app running -> visible in mobile
Linux CLI-only remote-control connected -> visible in mobile

This is confusing because the same CLI command works as expected on a Linux host.

What steps can reproduce the bug?

  1. On a macOS host with Codex CLI 0.133.0, make sure Codex.app is not running.

  2. Run:

    codex remote-control --json start
  3. Observe that the command reports:

    {
      "status": "connected",
      "timedOut": false
    }
  4. Confirm the CLI remote-control processes are running:

    codex app-server daemon pid-update-loop
    codex app-server --remote-control --listen unix://
  5. Open ChatGPT mobile and check the Codex remote host list.

  6. The macOS host is not shown.

  7. Launch Codex.app on the same macOS host:

    open -a Codex
  8. The host becomes visible in ChatGPT mobile.

For comparison, on a Linux host with the same CLI version, running only:

codex remote-control --json start

is enough for the host to appear in ChatGPT mobile.

What is the expected behavior?

Either:

  1. codex remote-control start on macOS should make the host visible in ChatGPT mobile, just like it does on Linux; or
  2. the CLI should clearly report that macOS mobile visibility requires Codex.app to be running / configured, instead of returning only status: connected.

The current connected status is misleading because the relay websocket appears connected, but the host is not visible or usable from mobile.

Additional information

I inspected the local state on the macOS host and noticed multiple remote-control enrollments:

app_server_client_name = Codex Desktop
app_server_client_name = Codex Desktop
app_server_client_name = <empty>

The CLI-started daemon appears to use the empty app_server_client_name enrollment, while Codex.app uses a Desktop-style identity. This might explain why the macOS CLI enrollment connects at the relay layer but is not surfaced in the mobile host picker.

I also checked the implementation path in the repository:

  • remote_control/protocol.rs normalizes https://chatgpt.com/backend-api into:
    • enroll URL: /wham/remote/control/server/enroll
    • websocket URL: /wham/remote/control/server
  • remote_control/websocket.rs publishes Connected after the websocket connects.

So this may be a product/identity/filtering mismatch rather than a pure network problem.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

codex - 💡(How to fix) Fix CLI remote-control reports connected on macOS but host is not visible in mobile unless Codex.app is running