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

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   extensionIssues related to the VS Code extensionIssues related to the VS Code extension

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   app-serverIssues involving app server protocol or interfacesIssues involving app server protocol or interfaces

   connectivityIssues involving networking or endpoint connectivity problems (disconnections)Issues involving networking or endpoint connectivity problems (disconnections)

   on Jul 11, 2026
2. ForthtuN commented on Jul 12, 2026

   

   ForthtuN

   on Jul 12, 2026

   More actions

   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"
3. outgrows commented on Aug 15, 2026

   

   outgrows

   on Aug 15, 2026

   More actions

   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
4. zemeng5208 commented on Aug 16, 2026

   

   zemeng5208

   on Aug 16, 2026 – with ChatGPT Codex Connector

   More actions

   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: zemeng5208/winbridge-recovery#4
5. bherreraicon commented on Sep 10, 2026

   

   bherreraicon

   on Sep 10, 2026 – with ChatGPT Codex Connector

   Last edited by bherreraicon

   More actions

   Confirmed additional root cause / workaround on Windows: stale CODEX_CLI_PATH

   We confirmed an additional cause of Unable to connect to Codex app-server at ws://127.0.0.1:<port>. This is not a universal fix for that message.

   In our installation, a stale user-level environment variable pointed to a nonexistent executable:

   CODEX_CLI_PATH=%LOCALAPPDATA%\OpenAI\CodexCLI\codex.exe
   

   extension-host.exe inherited this variable, overriding the valid CLI path in chrome-native-hosts-v2.json. Native Messaging registration was valid, the host listened on the advertised TCP port, and TCP tests passed. However, starting the app-server failed:

   Failed to start Codex app-server ... (os error 3)
   

   The excerpt is abbreviated and the personal path is omitted. The host closed the connection before returning HTTP 101 Switching Protocols; Chrome reported WebSocket 1006.

   Check first — these commands do not modify anything:

   $cliOverride = Get-ItemPropertyValue 'HKCU:\Environment' 'CODEX_CLI_PATH' -ErrorAction SilentlyContinue
   
   if ([string]::IsNullOrWhiteSpace($cliOverride)) {
       'No user-level override found; this specific workaround does not apply.'
   } else {
       $cliTarget = [Environment]::ExpandEnvironmentVariables($cliOverride)
       Test-Path -LiteralPath $cliTarget -PathType Leaf -ErrorAction Stop
   }

   If the check returns False, investigate whether this is genuinely an obsolete override. Do not remove an intentional override or assume every connection failure has this cause.

   Workaround for the confirmed stale-override case:

   Back up the individual registry value first, including its name, type and data. Confirm that the app-managed CLI exists and that the obsolete override is no longer needed. Then remove only the user-level variable:

   # Only after the checks and backup described above:
   [Environment]::SetEnvironmentVariable(
       'CODEX_CLI_PATH',
       [NullString]::Value,
       'User'
   )

   Fully exit Codex and Chrome, including background processes, then relaunch them with the updated environment. Restarting only the side panel is insufficient. Avoid launching from a terminal that still carries the old value; sign out and back in if necessary.

   Verified result: removing the override made the same host use the valid app-managed CLI, return HTTP 101, and complete initialize. After fully restarting Codex and Chrome, the actual Chrome side panel worked. The isolated A/B test also reproduced failure with the override and success without it.

   The successful repair removed only HKCU\Environment\CODEX_CLI_PATH, after backup. It did not require deleting .codex, modifying WindowsApps, or hard-coding another CLI path.

   A useful diagnostic improvement would be to report the effective CLI path, whether an environment override supplied it, and the app-server startup error.

   Keep diagnostic output and backups private unless personal paths and other sensitive values have been redacted.
6. pzh200707 commented on Sep 16, 2026

   

   pzh200707

   on Sep 16, 2026

   More actions

   I have used Gemini 3.8 Flash analyzed the problem and resolved with multiple trials. mklink seems the solution for this problem.

   Here is Gemini report:

   1. Symptoms & Incident Context

   • Symptoms:
     • The Edge ChatGPT companion/sidepanel window displayed:

       Unable to connect to ChatGPT
       Unable to connect to Codex app-server at ws://127.0.0.1:<ephemeral-port>/?token=...

     • Accompanied by CLI / app errors: Connection failed: error sending request.
     • Every relaunch picked a new random high port (e.g., 51995, 59533, 50585), and clicking "Try again" never recovered.

   ---

   2. Root Cause Analysis

   Through binary disassembly of extension-host.exe, inspecting the Edge extension's unpacked bundle, and tracing live Native Messaging RPC calls, three interconnected root causes were identified:

   A. In-Memory Environment Variable Poisoning (CODEX_CLI_PATH)

   • The Trap: While CODEX_CLI_PATH had been removed from the registry (HKCU:\Environment), Windows never dynamically updates the environment block of running processes. Background Edge instances (e.g., msedge.exe --no-startup-window) still retained the stale environment table in memory containing:
     CODEX_CLI_PATH = C:\Users\Administrator\AppData\Local\OpenAI\Codex\bin\fd4c151a749f3ab4\codex.exe
   • The Binary Behavior: Reverse engineering of extension-host.exe revealed that during initialization, it calls std::env::var("CODEX_CLI_PATH"). If this variable is detected in the process environment, it overrides paths.codexCliPath from chrome-native-hosts-v2.json.
   • The Failure: When Edge spawned extension-host.exe via Native Messaging stdio, the child process inherited this dead path. Upon receiving a WebSocket handshake from the sidepanel, extension-host.exe attempted to launch fd4c151a749f3ab4\codex.exe, failed immediately with The system cannot find the file specified, and abruptly dropped the TCP connection (leaving the sockets in TIME_WAIT).

   B. Windows AppContainer Loopback Isolation on Microsoft Edge

   • Edge extensions and WebViews run inside Windows AppContainers, which by default block connections to localhost (127.0.0.1).
   • While loopback exemptions had previously been granted to OpenAI.Codex and OpenAI.ChatGPT-Desktop, Edge (Microsoft.MicrosoftEdge.Stable_8wekyb3d8bbwe) was missing from the Windows LoopbackExempt list, intermittently causing WebSocket connection handshakes to 127.0.0.1 to be blocked at the OS packet filter level.

   C. Sidepanel Frontend React Retry Deadlock

   • Inspection of the extension's sidepanel bundle (chrome-extension-codex-app-sR7B_cuz.js) revealed that the "Try again" button merely increments an internal retry counter.
   • It does not re-invoke ensure_codex_app_server to retrieve an updated URL; it loops indefinitely trying to reconnect to the exact dead port (e.g., 50585) that was captured when the sidepanel initially loaded.

   ---

   3. Remediation & Solutions Implemented

   1. Hardware-Level Directory Junction Fallback (Permanent Immunity)

      • Created an NTFS directory junction linking the stale hash directory to the current valid installation:

        mklink /J "C:\Users\Administrator\AppData\Local\OpenAI\Codex\bin\fd4c151a749f3ab4" "C:\Users\Administrator\AppData\Local\OpenAI\Codex\bin\12219cbfbcbddde7"

      • Result: Even if a long-running process or legacy script passes the old fd4c151a749f3ab4 path, the Windows filesystem instantly and transparently resolves it to the active codex.exe.

   2. Loopback Exemption Granted to Microsoft Edge

      • Whitelisted Edge's AppContainer package identity to permit uninhibited loopback TCP connections to 127.0.0.1:

        CheckNetIsolation.exe LoopbackExempt -a "-n=Microsoft.MicrosoftEdge.Stable_8wekyb3d8bbwe"

   3. Bridge Process Flush and Re-synchronization

      • Terminated orphaned and zombie instances of extension-host.exe.
      • Edge automatically respawned a clean native host instance (extension-host.exe), which in turn cleanly spawned the backend daemon:
        "codex.exe" app-server --analytics-default-enabled (PID: 39880).

   ---

   4. Verification & Current Status

   Live network socket inspection confirms the full pipeline is connected and operational:

   • Host Process: extension-host.exe (PID: 15892) is listening on 127.0.0.1:55458.
   • Daemon Process: codex.exe (PID: 39880) is actively running under extension-host.exe.
   • Edge Client: msedge.exe (PID: 2984) is connected to the bridge:

     LocalAddress: 127.0.0.1:55458 <---> RemoteAddress: 127.0.0.1:60153 (msedge.exe)
     State: Established
     
7. GoZippy commented on Sep 22, 2026

   

   GoZippy

   on Sep 22, 2026 – with ChatGPT Codex Connector

   Last edited by GoZippy

   More actions

   On my Windows 10 PC (build 19045), ChatGPT Desktop is 26.915.4065.0, the bundled Codex CLI is 0.155.0-alpha.9.2, and the ChatGPT Chrome extension is 1.26.901.11451. The side panel reports Native host request codeRuntime/hello timed out after 5000ms.

   I confirmed Chrome is running, the extension is installed and enabled in the selected profile, and its Native Messaging manifest and registry entry are present and agree. codex doctor reports config/auth/database healthy and a successful WebSocket upgrade to chatgpt.com, but no desktop app-server handshake. The browser-client setup separately fails before a tab request with e.nodeRepl?.setResponseMeta is not a function; I do not know whether those failures share a cause.

   Defender real-time protection is enabled. I found no Defender detection/remediation or ASR block/audit event, and no AppLocker block in the queried seven-day window. The registered native-host executable did start. Malwarebytes services and kernel drivers are active, but I found no evidence tying them to this failure.

   A read-only Windows Firewall check found the active profiles are Public. ChatGPT's inbound rules for local ports 1455/1457 point to a K:\WindowsApps\... path, while the running Desktop processes use C:\Program Files\WindowsApps\...; the current C: path has inbound rules allowing Private and blocking Public. I found no listener in the ports/ranges named by these rules, so the path mismatch may matter if the app server starts but does not prove why it is currently absent. The enabled offline outbound rule is scoped to the separate CodexSandboxOffline account, not my signed-in user. OpenAI's package host answers HTTPS requests from this PC. I made no firewall or security-setting changes.

   These failures may be related to the app-server/runtime readiness reports here, but this evidence does not prove a common root cause. Could the diagnostics distinguish Native Messaging hello, Desktop app-server readiness, and browser-runtime/tool-call compatibility, and identify which stage failed? No account identifiers, tokens, or conversation content are included.

   Correction from a later read-only check the same day: Ethernet and Tailscale reported Private, not Public. I did not retest the Chrome panel after that profile change. A fresh ActiveStore firewall-rule query returned Access Denied, so I could not refresh the path-specific rule inventory; no listener appeared in the previously checked app-server port range. This narrows the earlier firewall observation to a point-in-time lead and does not establish a current firewall cause.