Windows Chrome side panel repeatedly loses Codex app-server after Native Messaging registry entry is removed

Summary

On Windows, the ChatGPT/Codex Chrome side panel repeatedly loses its local Codex app-server connection. Restarting Chrome or Codex only changes the loopback port and token; the same failure returns.

Unable to connect to ChatGPT
Unable to connect to Codex app-server at
ws://127.0.0.1:<dynamic-port>/?token=<redacted>&clientId=sidepanel-window-<redacted>

Observed loopback ports across reproductions included 51321, 53231, and 53142. All tokens and client identifiers are intentionally redacted.

This report adds a narrower lifecycle finding to the existing Windows Native Messaging Host reports: the missing HKCU registration can be created successfully, Chrome control immediately starts working, but the registry entry is then removed again shortly after the native host starts. The workaround therefore does not survive a host restart.

Environment

• Windows NT 10.0.26200 x64, 25H2
• Codex Desktop runtime/app version observed in local runtime state: 26.803.81509
• Bundled Chrome plugin: 26.803.81509
• Google Chrome: 151.0.7922.138
• Native host: com.openai.codexextension
• Stable Chrome extension ID: hehggadaopoacecdllhhajmbjkdcmajg
• Edge-compatible extension ID also present in the manifest: odlomjlbamekndcpllcnffbgeohgkmjh

Reproduction

1. Install/enable the bundled Chrome plugin in Codex Desktop and install/enable the ChatGPT Chrome extension.
2. Open the ChatGPT/Codex Chrome side panel.
3. Observe Unable to connect to Codex app-server with a loopback WebSocket URL.
4. Fully restart Chrome and Codex.
5. Reopen the side panel.
6. Observe the same error with a different loopback port and token.
7. Repeat plugin/extension reinstall or repair. The failure returns.

Static state before repair

The native host manifest existed:

%LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json

The manifest was structurally valid and pointed to an existing executable:

%USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host.exe

It contained the expected host name and allowed extension origins. Both copies of chrome-native-hosts-v2.json also contained the current runtime entry and valid paths.

However, the required registration was absent:

HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension

Direct reg.exe query, not only the bundled checker, confirmed that the key was missing.

Controlled repair experiment

1. Backed up the manifest and Chrome native-host runtime state.
2. Created the missing HKCU unnamed REG_SZ value pointing to the existing manifest:

reg.exe add "HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension" `
  /ve /t REG_SZ `
  /d "$env:LOCALAPPDATA\OpenAI\extension\com.openai.codexextension.json" `
  /f

1. Immediately verified that the registry value existed and pointed to the correct manifest.
2. Terminated only the two stale extension-host.exe processes whose executable path exactly matched the bundled Chrome plugin host.
3. Chrome immediately launched two fresh extension-host.exe processes.
4. The Codex Chrome backend became available again.
5. browser.user.openTabs() successfully returned the real open Chrome tabs.
6. The same connection was tested again 10 seconds later and still returned the real tabs.

Critical lifecycle result

Shortly after the successful startup, the registry entry had disappeared again.

The disappearance was confirmed independently through all three views:

reg.exe query "HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension" /ve /reg:64
reg.exe query "HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension" /ve /reg:32
Get-ItemProperty 'Registry::HKEY_CURRENT_USER\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension'

Both reg.exe views returned that the key/value did not exist, and the PowerShell registry provider returned no item.

This was not the previously reported localized (Default) parsing false positive. The registration was genuinely present immediately after reg.exe add and genuinely absent after native-host startup.

The already-running Chrome backend continued to work temporarily because the new host processes were alive, but the registration required for a later relaunch was gone.

Additional runtime symptoms

• A failing loopback endpoint may briefly return HTTP/WebSocket 403 and then stop listening.
• By the time diagnostics run, the port shown in the side-panel error can have no listener.
• extension-host.exe processes may remain even when no relevant TCP listener exists.
• The side panel continues displaying the now-stale loopback URL instead of obtaining a fresh endpoint or explaining that the host exited.
• Before the controlled repair, repeated Chrome backend checks returned Browser is not available.
• Reinstalling/restarting changes the dynamic endpoint but does not repair the lifecycle.

Diagnostic ambiguity

The bundled check-native-host-manifest.js reports the missing HKCU registration, but the broader issue cluster also contains two distinct checker problems:

1. localized reg.exe unnamed-value labels such as (padrão) or (par défaut) can be misparsed as missing;
2. spawnSync reg EPERM can be collapsed into the same user-facing missing-key result.

A diagnostic should distinguish:

• registry query failed;
• registry key genuinely missing;
• key exists but points to the wrong manifest;
• key existed but was removed during/after host reconciliation.

On this machine, final direct queries confirmed the checker result was a real missing key after deletion, not a localization false positive.

Expected behavior

• Installing or repairing the Chrome plugin should idempotently create the native-host manifest and HKCU registration.
• Starting the native host must not remove the registration required for its next launch.
• If Codex intentionally uses an ephemeral registration, it must reliably recreate it before every Chrome connection.
• The side panel should discard a dead/stale loopback endpoint and request a fresh one.
• Stale or duplicate extension-host.exe processes should be detected and cleaned up without deleting valid persistent registration.
• Plugin state must not show installed/enabled when the required native-host layers are absent.
• Diagnostics should report the exact failed layer.

Actual behavior

• The plugin/extension can appear installed and enabled while the required registry pointer is absent.
• A manual pointer temporarily restores Chrome control.
• The pointer is removed again shortly after host startup.
• The current live host may work temporarily, but the next host restart is expected to fail again.
• The side panel repeatedly reports a new dynamic port/token without recovering.

Suggested fixes

1. Make native-host installation and repair an idempotent, independently callable step.
2. Trace and stop the code path that removes the valid HKCU registration after successful host startup.
3. If removal is intentional, atomically recreate the registration before every connection and validate the new host before publishing the WebSocket URL.
4. Store the host executable in a stable non-cache location rather than a mutable latest plugin-cache target.
5. Reconcile host process lifetime, registry lifetime, manifest lifetime, and side-panel endpoint lifetime as separate states.
6. Make plugin installation atomic: either every required layer succeeds, or the plugin remains uninstalled with a precise error.
7. Parse the registry through a locale-independent API and distinguish query errors from actual absence.

Related issues

• #21674 — Chrome plugin install fails although the extension is enabled
• #22558 — app says connected while the Chrome extension stays disconnected
• #23283 — reinstall does not create the native messaging host
• #24040 — manifest exists but HKCU registry pointer is missing
• #24296 — native host runs from mutable cache and can lock plugin reconciliation
• #28950 — Windows installer lifecycle leaves host state inconsistent
• #31152 — newer Windows reproduction with plugin enabled but host missing
• #32802 — current-generation Windows reproduction where host files/registration are never created

The new evidence here is the controlled transition:

registry absent
  -> manual registration succeeds
  -> Chrome launches fresh native hosts
  -> real Chrome control succeeds
  -> registration is removed again
  -> current host may work temporarily
  -> next relaunch is no longer registered

Privacy / security

• No WebSocket token, authentication token, cookie, API key, account ID, install ID, or Chrome profile data is included.
• No auth.json content was read or attached.
• User paths are represented only through environment-variable placeholders.