Remote control stays offline after switching Business accounts; enrollment fails with MFA required

Open 💬 2 comments Opened May 22, 2026 by patppham

What happened?

Codex mobile remote control stopped connecting after switching between two ChatGPT Business accounts on the same Windows PC / Codex Desktop install.

Setup:

  • Windows PC running Codex Desktop from Microsoft Store / WindowsApps
  • Codex Desktop launches WSL app-server (runCodexInWindowsSubsystemForLinux = true)
  • Two different ChatGPT Business accounts are used on the same Windows Codex Desktop install and matching iPhone ChatGPT app sessions
  • Remote control worked previously for both accounts when signing out/in on desktop and iPhone

After switching accounts, mobile now sees the computer but reports it as offline / last seen ~11 hours ago. Switching back to the account that worked previously no longer fixes it.

Expected behavior

After signing into the same Business account/workspace on Codex Desktop and ChatGPT iOS, the mobile app should show the desktop as online and allow remote control.

Actual behavior

The mobile app only shows a stale computer record as offline / last seen hours ago. Locally, no fresh remote_control_enrollments row is created for the currently signed-in Business account.

Relevant logs / diagnostics

Windows-side Codex logs show remote control attempting to enroll, then failing with MFA required:

remote control server enrollment failed at `https://chatgpt.com/backend-api/wham/remote/control/server/enroll`: HTTP 403 Forbidden
body: {"detail":"Multi-factor authentication required"}

One example request id from the local logs:

request-id: d1591fd5-7d6c-4097-a6cc-d9594ad6d5f9
cf-ray: 9ff792f04e528de9-SIN

The local app-server process is running and remote control is enabled:

/mnt/c/Users/.../.codex/bin/wsl/.../codex app-server --analytics-default-enabled
CODEX_HOME=/home/.../.codex-app
{"status":"alreadyEnabled","remoteControlEnabled":true,"socketPath":"/home/.../.codex-app/app-server-control/app-server-control.sock","cliVersion":"0.133.0-alpha.1"}

Config tried

All relevant configs have both flags enabled:

[features]
remote_control = true
remote_connections = true

The desktop WSL config also has:

[features]
goals = true
remote_control = true
remote_connections = true

Workarounds tried

  • Signed out/in on desktop and iPhone with matching Business workspace
  • Refreshed CLI auth for WSL and Windows-side Codex
  • Restarted Codex Desktop
  • Cleared local remote_control_enrollments rows from:
  • ~/.codex-app/state_5.sqlite
  • ~/.codex/state_5.sqlite
  • C:\Users\...\.codex\state_5.sqlite
  • Added both remote_control = true and remote_connections = true
  • Tried Windows codex.exe remote-control, but it fails because the daemon lifecycle is Unix-only:
Error: codex app-server daemon lifecycle is only supported on Unix platforms
  • Tried WSL codex remote-control start --json, but this install lacks the standalone daemon-managed path:
managed standalone Codex install not found at ~/.codex-app/packages/standalone/current/codex

Notes

This may be related to account switching / MFA state not being propagated to remote-control enrollment. The visible mobile computer appears to be server-side stale after local enrollment rows are cleared.

Potentially related issues: #19301, #4432, #6506.

View original on GitHub ↗

2 Comments

patppham · 3 months ago

Additional diagnostic from trying the WSL CLI remote-control workaround:

codex remote-control
Starting app-server with remote control enabled...
Error: Remote control is enabled on [machine-name] but the connection is errored.

The bubblewrap message appears non-fatal because Codex says it will use bundled bubblewrap. The actual WSL CLI remote-control failure in ~/.codex/logs_2.sqlite is now auth-related:

remote control server enrollment failed at `https://chatgpt.com/backend-api/wham/remote/control/server/enroll`: HTTP 401 Unauthorized
body: {
  "error": {
    "message": "Your authentication token has been invalidated. Please try signing in again.",
    "type": "invalid_request_error",
    "code": "token_invalidated"
  },
  "status": 401
}

remote control websocket auth recovery failed: mode=managed, step=refresh_token:
Your access token could not be refreshed because your refresh token was revoked. Please log out and sign in again.

This is distinct from the earlier Windows/Desktop enrollment failure that returned HTTP 403 with {"detail":"Multi-factor authentication required"}.

patppham · 3 months ago

Confirmed workaround and external corroboration:

A related Reddit report describes the same Windows Desktop/iOS remote connection failure pattern: the iOS app still sees the Windows Codex Desktop computer, but it remains offline / stuck reconnecting after a Windows Codex update.

Reddit thread: https://www.reddit.com/r/codex/comments/1tf8ogt/windows_codex_desktop_remote_connection_broke/

Workaround that succeeds for me:

  1. Use the WSL/Linux Codex CLI remote-control host instead of the Windows Desktop remote host.
  2. Refresh WSL CLI auth first if needed:
codex logout
codex login
  1. Start remote control from WSL:
codex remote-control

After a successful login, this prints:

Starting app-server with remote control enabled...
Codex could not find bubblewrap on PATH... Codex will use the bundled bubblewrap in the meantime.
This machine is available for remote control as [machine-name].
Press Ctrl-C to stop.

The bubblewrap line is non-fatal. The important part is This machine is available for remote control as [machine-name].

On iOS, I now see two devices:

  • a new WSL CLI [machine-name] device that is online and works
  • the old Windows Codex Desktop [machine-name] computer/app entry, still offline / stale

So the backend/mobile path is capable of connecting to this machine via WSL CLI. The broken path appears specific to Windows Codex Desktop remote enrollment/connection, especially after account switching / MFA / update state.

Caveat: WSL CLI remote sessions do not appear to sync with Codex Desktop sessions because they use different Codex homes (~/.codex vs ~/.codex-app), but they can operate on the same filesystem/workspace.