Windows Codex Desktop remote-control QR pairing remains stuck after stale remote hosts are cleaned up

Open 💬 3 comments Opened Jun 26, 2026 by pensacola1989

What issue are you seeing?

After upgrading to Codex Desktop 26.623.31443 (released Jun 26, 2026) with app-server 0.142.2, remote host/project selection got stuck on stale remote-control environments.

I was able to recover the Mac mini remote projects by removing stale remote-control environment records and resetting selected-remote-host-id back to the current Mac mini environment. However, Windows Codex Desktop still cannot be paired/controlled: scanning the QR code stays stuck and the Windows connection never completes.

This is disappointing because this is a core remote-workflow feature. After upgrading to the latest Codex Desktop, I expected remote host selection and pairing to become more reliable, but instead remote projects disappeared, stale hosts won selection, and the Windows pairing flow still cannot recover even after manual cleanup. For a workflow that depends on switching between macOS, a Mac mini, and Windows, the current behavior makes the feature feel fragile and hard to trust.

This also cost a significant amount of time to diagnose and recover. I had to inspect local state files, desktop logs, backend environment responses, stale environment IDs, and manually clean up remote-control records just to get the Mac mini projects back. The Windows flow is still blocked after that, so this is not just a minor UI glitch; it has already caused real debugging overhead and interrupted normal work.

More broadly, Connections/remote-control has repeatedly broken for me after Codex updates. When each update risks breaking remote hosts, hiding projects, or forcing manual state/backend cleanup, it creates a strong disincentive to update Codex at all. I want to stay current, but this pattern makes updates feel risky because the remote workflow may need another round of manual recovery afterward.

This looks related to the existing Windows/mobile remote-control reports, but this case has an additional stale-host selection component:

  • Mac mini remote projects were hidden until stale env records were removed.
  • After cleanup, Mac mini works again.
  • Windows still fails at QR/mobile pairing.

Steps to reproduce

  1. Use the same ChatGPT account with Codex Desktop on macOS, a remote Mac mini, and a Windows Codex Desktop host.
  2. Upgrade Codex Desktop to 26.623.31443 / app-server 0.142.2.
  3. Have multiple historical remote-control environments for the same account, including stale/offline Windows and old Mac mini entries.
  4. Open Codex Desktop on macOS and inspect remote projects / Connections.
  5. Try to re-enable or reconnect the Windows Codex Desktop remote-control setup by scanning the QR code.
  6. Observe that QR pairing remains stuck and Windows never becomes usable as a remote-control target.

Expected behavior

  • Stale/offline remote-control environments should not steal selection from the current online host.
  • The remote project selector should show the current Mac mini projects consistently.
  • Windows Codex Desktop QR pairing should complete or surface a clear actionable error.
  • Codex updates should preserve existing Connections state safely, or provide a supported repair path when migration fails.

Actual behavior

  • Before cleanup, Codex selected stale remote-control environments even when a current Mac mini host was online.
  • The remote project selector could flash briefly and disappear.
  • After deleting stale Windows and old Mac mini environment records, the Mac mini project list recovered.
  • Windows Codex Desktop still cannot complete QR pairing; scanning the QR code leaves the setup stuck.
  • The issue reinforces a recurring pattern where updating Codex breaks Connections and makes future updates feel unsafe.

Diagnostics

Local state after cleanup only references the current Mac mini host:

{
  "selected": "remote-control:env_e_6a0660...",
  "added": ["env_e_6a0660..."],
  "remoteProjectHosts": ["remote-control:env_e_6a0660..."]
}

Relevant macOS Codex Desktop log pattern before cleanup:

[remote-connections/selection] persisted_selection_reconciled \
  persistedSelectedRemoteHostId=remote-control:env_e_6a0660... \
  selectedRemoteHostId=remote-control:env_e_6a2cbd...

Request failed method=remoteControl/status/read \
  error="Connection for host ID remote-control:env_e_6a2cbd... not found"

After cleanup, the client-specific environment list only returned the current Mac mini env and Mac mini remote projects recovered, but Windows QR pairing still remains stuck.

Related issues that appear similar or adjacent:

  • #22733
  • #25733
  • #25904
  • #25532
  • #23112

Environment

  • Codex Desktop macOS: 26.623.31443
  • app-server: 0.142.2
  • Current working remote host: Mac mini, app-server 0.142.2
  • Failing host: Windows Codex Desktop remote-control QR pairing
  • Mobile app: ChatGPT mobile app scanning Codex QR code

Additional notes

The issue may involve two separate problems:

  1. stale remote-control environments can incorrectly win selectedRemoteHostId reconciliation;
  2. Windows Codex Desktop QR pairing remains stuck even after the stale host records are removed and macOS/Mac mini remote control works again.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗