Chrome extension side panel cannot connect to local Codex app-server on Windows

Open 💬 3 comments Opened Jul 11, 2026 by egore4606

Summary

The ChatGPT Chrome Extension side panel displayed “Unable to connect to ChatGPT” and could not connect to the local Codex app-server over a loopback WebSocket (ws://127.0.0.1:<port>/…). The opaque query token from the UI has been intentionally omitted.

Impact

Codex could not control the user's existing Chrome profile through the extension while the error was shown.

Environment

Windows
Google Chrome with the ChatGPT Chrome Extension
Codex Desktop
Observed on 2026-07-11

Observed behavior

The extension side panel showed:

Unable to connect to ChatGPT Unable to connect to Codex app-server at ws://127.0.0.1:<port>/…

Expected behavior

The extension should reliably connect to the running Codex Desktop app-server, or surface a clear recovery action and diagnostic if the local app-server is unavailable.

Notes

A subsequent lightweight connection check from Codex was able to list the Chrome tabs successfully. This suggests the failure may be intermittent or tied to the local app-server lifecycle/readiness rather than the extension simply being absent or disabled.

Please investigate local app-server startup/restart behavior and the extension's WebSocket reconnect/error reporting on Windows.

Related, but not an exact duplicate: #30688 (Chrome backend unavailable despite extension/native host working).

View original on GitHub ↗

3 Comments

ForthtuN · 1 month ago

Having the exakt same problem "Unable to connect to ChatGPT
Unable to connect to Codex app-server at ws://127.0.0.1:56806/?token=xxxxxxxxxxxxxx&clientId=sidepanel-window-249992520"

outgrows · 12 days ago

Facing the same issue only on one desktop device with windows 11 latest ver, works fine on another laptop with windows 11 latest ver. and have tried deleting every files and reinstalling codex entirely and still couldn't fix the issue

zemeng5208 · 12 days ago

I maintain WinBridge Recovery, an independent Windows recovery/diagnostic tool for Codex Desktop local plugin/runtime state.

The recent report that this works on one Windows 11 machine but still fails on another even after deleting/reinstalling Codex is a useful clue: a Store reinstall can replace the AppX package while leaving user-side Codex/Chrome integration state inconsistent.

For this failure class, WinBridge can compare the currently installed official AppX resources against the user-side bundled Chrome plugin cache/version/latest, the Native Messaging manifest + HKCU registration, chrome-native-hosts-v2.json, and the local runtime/app-server paths those records point to. If those layers are stale or version-split, it can rebuild the user-owned state from the already installed official package with staging, verification, backup and rollback rather than modifying WindowsApps.

The important boundary is the loopback app-server itself: if the Chrome/native-host/runtime state is internally consistent and the side panel still cannot connect to the ws://127.0.0.1:<port> endpoint, that points back to an upstream app-server lifecycle/readiness/reconnect problem rather than something a local cache repair should pretend to fix.

If anyone on this thread tries WinBridge, success, partial success, and failure reports are all useful. I keep a small outcome thread here: https://github.com/zemeng5208/winbridge-recovery/issues/4