Windows Remote Control fails after auto-update 26.715.4045.0 -> 26.715.9079.0 (works before, broken after)

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

• #34682
• #34689

Powered by Codex Action

It works now with the latest Version 26.721.30844

It's not working with mac at the latest version.

It's not working with mac at the latest version.

Did you try not with the QR code but manually with the code?
sometimes the QR code setup is not working properly

Update (2026-08-04): this is still reproducible on a newer OS and app build:

• Windows 11 25H2, build 26200.8875 (in-place upgrade from Windows 10)
• Codex Desktop 26.727.6591.0

The app itself now starts normally after I fixed an unrelated stale proxy configuration and restored the Windows certificate-revocation path. I verified that the local proxy is healthy, the Codex update endpoint returns HTTP 200, the OpenAI API is reachable (expected unauthenticated 401), and GitHub access works.

However, enabling Control this computer still fails before any QR code or manual pairing code is shown.

Fresh Sentry breadcrumbs provide a more precise failure:

• GET /backend-api/wham/remote/control/mfa_requirement -> 200
• repeated requests to /backend-api/wham/remote/control/environments/.../clients -> 403 Forbidden
• the 403 response is a Cloudflare block page, with CF-RAY ending in DME

At the same time, https://chatgpt.com/cdn-cgi/trace through the configured local proxy reports loc=IT. This suggests that the remote-control request made by the Codex app-server bypasses the configured WinINET/PAC proxy and exits directly through Moscow, while the Electron/login traffic uses the proxy successfully.

So the issue remains in 26.727.6591.0, and this is not a QR-code setup problem: enrollment cannot begin because the client-list request is blocked first.

Confirmed workaround / root-cause update:

Remote Control now works on:

• Windows 11 25H2, build 26200.8875
• Codex Desktop 26.727.6591.0

The PAC configuration itself was correct and routed *.chatgpt.com through the local proxy. Electron traffic honored it (for example, mfa_requirement returned 200), but the codex.exe app-server Remote Control request did not appear to honor WinINET/WinHTTP PAC autoconfiguration. It exited directly through Moscow and received a Cloudflare HTML 403 with CF-RAY ending in DME.

I relaunched the installed ChatGPT.exe with proxy variables scoped only to the ChatGPT/Codex process tree:

$env:HTTP_PROXY  = "http://127.0.0.1:2081"
$env:HTTPS_PROXY = "http://127.0.0.1:2081"
$env:ALL_PROXY   = "http://127.0.0.1:2081"
$env:NO_PROXY    = "localhost,127.0.0.1,::1"

$package = Get-AppxPackage -Name OpenAI.Codex
& (Join-Path $package.InstallLocation "app\ChatGPT.exe")

With the same authenticated account:

• the environments endpoint returned HTTP 200 through the proxy, with CF-RAY ending in MXP;
• the regional 403 DME disappeared;
• Control this computer enabled successfully.

This is process-scoped and does not require a global Windows proxy. The observed behavior suggests that the Windows app-server should either honor the system PAC settings or provide a documented per-app proxy setting for Remote Control.

Windows Remote Control still fails on Codex 26.810.7004.0

I can confirm that this issue is still reproducible on Codex for Windows 26.810.7004.0 (Microsoft Store/MSIX) on Windows 11.

Observed behavior

Settings → Connections → Control this computer → Add → Allow

Initially, Codex showed:

Unable to enable remote control. Please make sure only one ChatGPT instance is running.

After subsequent attempts, the message changed to:

Unable to enable remote control. Please try again.

No pairing code is generated and no remote device can be added.

Troubleshooting / diagnostics performed

Confirmed there is only one ChatGPT/Codex main instance.
Main process: ChatGPT.exe
All other ChatGPT.exe processes are normal Chromium/Electron child processes (renderer, gpu-process, utility, crashpad-handler, etc.).
codex.exe is a child of the same main ChatGPT.exe process.
codex-code-mode-host.exe is a child of that codex.exe.
There is no second independent ChatGPT/Codex process tree.
Codex desktop logs show that the Remote Control RPC is actually being handled.

Example:

method=remoteControl/enable ... errorCode=null

This happens repeatedly.

Immediately afterwards, however, Remote Control remains:

previousConnectionCount=0

nextConnectionCount=0

autoConnectConnectionCount=0

remoteControl/client/list also continues to return without establishing a connection.

Checked for a Remote Control listener.
Compared TCP listeners owned by ChatGPT/Codex before and immediately after pressing Allow.
No new listener appears.
Checked Windows Event Logs immediately after reproducing the failure.
Application
Microsoft-Windows-AppModel-Runtime/Admin
Microsoft-Windows-AppXDeploymentServer/Operational

No relevant Codex/ChatGPT/OpenAI/AppModel/AppX activation or permission errors were generated.

Monitored Windows process creation and termination while pressing Allow.
Captured Win32_ProcessStartTrace and Win32_ProcessStopTrace for 20 seconds around the Remote Control attempt.
No new process was created or terminated at all.
In particular, there was no new Remote Control host/daemon/helper process.

This suggests that the failure happens inside the Codex Remote Control enable/startup path before a Remote Control host/daemon is actually launched, rather than being caused by multiple ChatGPT instances, Windows Firewall, MSIX/AppModel activation, or a helper process being launched and then terminated.

The "only one ChatGPT instance" message also appears to be misleading in this case, since the process tree was explicitly inspected and only one main instance exists.

Environment

Windows 11
Codex: 26.810.7004.0
Installation: Microsoft Store / MSIX
Package: OpenAI.Codex_2p2nqsd0c76g0
ChatGPT account: Plus
Remote Control works correctly with the same account on macOS

I can provide the relevant Codex desktop logs and process traces if useful.

It would be helpful to know whether this is the same Windows Remote Control regression reported here, and whether there is currently a workaround or a fix planned for an upcoming Windows build.