Skip to content

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

Open
Open
Windows Remote Control fails after auto-update 26.715.4045.0 -> 26.715.9079.0 (works before, broken after)#34815
Labels
appIssues related to the Codex desktop appbugSomething isn't workingremotewindows-osIssues related to Codex on Windows systems

Description

@zinovevvv
zinovevvv
opened on Jul 22, 2026

Description

Remote Control ("Control this computer") stopped working after Codex Desktop auto-updated overnight. It worked fine before the update and consistently fails after, with no config/account/network changes on my end.

Environment

  • OS: Windows 10 Home Single Language, build 19045 (22H2)
  • Codex Desktop: auto-updated from 26.715.4045.0 to 26.715.9079.0 at 2026-07-22 02:53 (confirmed via Microsoft-Windows-AppXDeploymentServer/Operational event log, event ID 855: updateList: OpenAI.Codex_26.715.4045.0_x64__2p2nqsd0c76g0 is updating to OpenAI.Codex_26.715.9079.0_x64__2p2nqsd0c76g0)
  • Account: ChatGPT Plus, personal (not workspace/Team)
  • MFA: enabled and confirmed challenged at login (verified 2FA code was requested and entered)

Steps to reproduce

  1. Settings → Connections → "Control this computer"
  2. Toggle "Разрешить подключения" / Allow connections
  3. Spinner briefly appears, then: "Не удалось обновить доступность удалённого управления" / "Unable to enable remote control. Please try again."

What I've already ruled out

  • VPN/network/region: confirmed working proxy with loc=NL (non-blocked region) via chatgpt.com/cdn-cgi/trace; general login/token-exchange succeeds.
  • MFA: account has MFA enabled, confirmed challenged during this session's login (not a stale/unassured session).
  • Config: [features] remote_control = true is present in config.toml (was previously missing after a prior update, restored, restarted app, no change).
  • Multiple instances: confirmed only one Electron instance running (single process tree rooted at one ChatGPT.exe, one codex.exe backend).
  • Reinstall: fully uninstalled (Remove-AppxPackage) and reinstalled via Microsoft Store — same failure persists on the reinstalled (latest) version.
  • Windows Update: OS itself is fully up to date (LastInstallationSuccessDate same day); no OS-level change occurred around the failure window, only routine Defender signature updates.

Sentry breadcrumbs at time of failure

Repeated calls to:

GET https://chatgpt.com/backend-api/wham/remote/control/mfa_requirement -> 200

with no subsequent call to any enroll/enable endpoint visible in the local Sentry scope — suggesting the client aborts before attempting enrollment, without surfacing why.

Related issues

This looks related to #31387 and #32348, which report the same "spinner then generic failure, no pairing code" symptom on other recent Windows builds. Adding this report because I have a very precise before/after: works on 26.715.4045.0, broken on 26.715.9079.0, no other machine-side change, which may help narrow down the regression.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    remote
    on Jul 22, 2026

  2. github-actions commented on Jul 22, 2026

    @github-actions
    github-actionsBot
    on Jul 22, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. barclayslb commented on Jul 23, 2026

    @barclayslb
    barclayslb
    on Jul 23, 2026

    It works now with the latest Version 26.721.30844

  4. chenaptx commented on Jul 30, 2026

    @chenaptx
    chenaptx
    on Jul 30, 2026

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

  5. barclayslb commented on Aug 2, 2026

    @barclayslb
    barclayslb
    on Aug 2, 2026

    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

  6. zinovevvv commented on Aug 4, 2026

    @zinovevvv
    zinovevvv
    on Aug 4, 2026 – with ChatGPT Codex Connector
    Author

    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.

  7. zinovevvv commented on Aug 4, 2026

    @zinovevvv
    zinovevvv
    on Aug 4, 2026 – with ChatGPT Codex Connector
    Author

    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.

  8. popolvuh-lyn commented on Aug 16, 2026

    @popolvuh-lyn
    popolvuh-lyn
    on Aug 16, 2026

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingremotewindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions