›_ Codex Issues
Codex Issues / #30165

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

Open 💬 4 comments Opened Jun 26, 2026 by pensacola1989
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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 ↗

4 Comments

github-actions[bot] contributor · 2 months ago

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

  • #29233
  • #28862

Powered by Codex Action

dingjianhui123-create · 1 month ago

Additional Windows reproduction / evidence from another machine.

I am seeing the same stale remote-control host selection behavior on Windows, but with a very clear local-vs-runtime mismatch:

Environment:

  • Codex Desktop: OpenAI.Codex_26.623.9142.0_x64
  • Codex CLI: 0.142.4
  • Platform: Windows x64, zh-CN locale
  • Auth mode: ChatGPT auth

Observed state:

  • Local remote_control_enrollments contains only the current Windows host:
  • environment_id = env_e_6a19...
  • remote_control_enabled = 1
  • A stale Mac host is still being selected by Desktop:
  • remote-control:env_e_6a23...

I closed Codex Desktop completely and repaired both global state files so selected-remote-host-id pointed to the current Windows host:

selected=remote-control:env_e_6a19...
oldCount=0
oldAtomExists=False
Repair completed successfully.

After relaunching Codex Desktop, the app immediately overwrote the valid persisted selection with the stale Mac host. The Desktop log shows the mismatch directly:

[remote-connections/selection] persisted_selection_reconciled
availableConnectionCount=1
persistedSelectedRemoteHostId=remote-control:env_e_6a19...
selectedRemoteHostId=remote-control:env_e_6a23...

Immediately afterwards, the selected stale host cannot be resolved:

Request failed
method=remoteControl/status/read
error={"code":-32000,"message":"Connection for host ID remote-control:env_e_6a23... not found"}

So the local enrollment database is correct, and the manual state repair succeeds while Codex Desktop is closed. The bad state returns only when Desktop reconciles its remote connection list. That list appears to contain only the stale remote host, and Desktop lets it override the valid persisted current host even though the stale host cannot be resolved by the connection manager.

Expected behavior:

  • A stale remote-control host that returns Connection for host ID ... not found should not win selectedRemoteHostId reconciliation.
  • Desktop should fall back to the current valid local remote-control environment, or expose a clear cleanup action for stale remote-control devices.
  • Manual state repair should not be undone by a stale remote connection registry entry.
pinepoetry · 1 month ago

Additional Windows datapoint that looks very close to this stale remote-control host selection issue.

Environment:

  • Codex Desktop on Windows: 26.623.13972.0
  • Installed package: OpenAI.Codex_26.623.13972.0_x64__2p2nqsd0c76g0
  • Codex CLI: 0.142.5
  • Platform: Windows x64
  • Mobile client: ChatGPT Android
  • Auth mode: ChatGPT auth

Observed state after reinstalling Codex Desktop, revoking mobile access, re-pairing the Android device, and restarting Desktop:

selected-remote-host-id = remote-control:env_e_6a253...         # old/stale host
electron-local-remote-control-environment-id = env_e_6a1d077... # current Windows host
codex-mobile-has-connected-device = true
remote-project-connection-backfill-completed = true

The current mobile pairing works: ChatGPT Android connects to the current Windows PC and I can send messages to an existing Codex thread from mobile.

However, Codex Desktop still persists/selects the old remote-control host ID in .codex-global-state.json after restart. The old host was associated with a previous Windows machine name, while the current local environment ID is different.

User-visible impact:

  • Codex Desktop project/thread list appeared empty/missing.
  • ChatGPT mobile still showed the existing projects/threads.
  • Local data was not deleted.

Local data checks showed the underlying thread/project data was still present:

state_5.sqlite threads: 198
sqlite/codex-dev.db local_thread_catalog rows: 197
local-projects after repair: 27
project-order after repair: 27
thread-project-assignments after repair: 197

I tried local state repair while Codex Desktop was fully closed. Setting/resetting the selected host locally did not prevent Desktop from persisting the stale remote-control host again after restart.

I was able to restore the Desktop project list only by rebuilding local project metadata from the local thread catalog into .codex-global-state.json, including:

local-projects
project-order
project-writable-roots
thread-project-assignments
thread-workspace-root-hints

After that, the Desktop project list is visible again. But the stale selected host still remains:

selected-remote-host-id = remote-control:env_e_6a253...
local environment id    = env_e_6a1d077...

This seems consistent with the issue described above: a stale remote-control environment can continue to win or remain in Desktop host selection even after the current local host is valid and mobile remote access is working.

Expected behavior:

  • A stale remote-control host that no longer matches the current local environment should not remain selected.
  • Re-pairing mobile access should replace stale host selection or expose a supported reset/repair action.
  • Desktop should not hide local projects/threads when local SQLite thread data is intact.

I used Codex locally to inspect the relevant state files and summarize the diagnostics above.

rahi25149 · 26 days ago

I can independently reproduce the stale remote-host selection problem on a newer release, and it has materially blocked my development workflow.

Environment

  • Controller: ChatGPT/Codex Desktop for macOS
  • Desktop version: 26.727.51351 (build 6119)
  • Bundled app-server: 0.146.0-alpha.9.2
  • Target: Windows Codex Desktop host (hostname and environment ID redacted)
  • Observed: 2026-08-02 (Asia/Shanghai)

Authoritative state vs. local state

The remote-control backend correctly reported the Windows environment as offline:

{
  "online": false,
  "busy": false,
  "os": "Windows",
  "client_type": "CODEX_DESKTOP_APP",
  "app_server_version": "0.146.0-alpha.9.2",
  "last_seen_at": "2026-08-01T17:30:29.070627Z"
}

However, the macOS controller still persisted the offline environment as its current target:

selected-remote-host-id = remote-control:<redacted-env-id>
remote-connection-auto-connect-by-host-id[remote-control:<redacted-env-id>] = false

The desktop logs simultaneously showed all of the following:

refresh_remote_control_completed ... nextConnectionCount=1
Connection for host ID remote-control:<redacted-env-id> not found
remote_connections.manager_state_set ... nextState=disconnected

Despite the authoritative online=false state and the local manager being disconnected, the paired environment remained exposed as an available/current host. Requests continued to route toward the stale host ID, which prevented normal connection and remote project work.

Workaround used

I backed up ~/.codex/.codex-global-state.json, removed only:

  • selected-remote-host-id
  • the affected host entry under remote-connection-auto-connect-by-host-id

I deliberately preserved the device pairing and three cached remote-thread summaries. After restarting the desktop app, the controller could reload without the stale host being forced as the current target.

Expected behavior

When the authoritative environment is offline, or remoteControl/status/read returns “Connection for host ID ... not found”, selection reconciliation should:

  1. mark the host offline rather than available;
  2. fall back to local for the current/default target;
  3. distinguish “paired” from “currently reachable” in every host picker/tool surface;
  4. offer a supported Repair connection state action instead of requiring edits to an internal JSON file.

Impact and compensation request

This regression blocked my active development project for a significant amount of time. I had to stop normal engineering work, inspect desktop logs, compare backend presence data with local connection-manager state, identify the stale persisted selector, protect existing remote task history, and manually repair an internal Codex state file. The failure was not caused by my project or Windows application; it was a Codex Desktop state-reconciliation defect.

Because this caused substantial productivity loss and I am providing a current, independently verified reproduction with a narrowly tested workaround, I respectfully request that OpenAI consider appropriate compensation—such as service/account credits, a product bug reward if one applies, or formal researcher acknowledgment. Please contact me privately through my GitHub account if sanitized diagnostics or a feedback session ID would help.

Related: #30329 and #23112.