Windows: Chrome extension 1.2.27259.19709 rejects native host 26.814.41407 because runtimeConfig omits trustedBrowserClientSha256s

What issue are you seeing?

Summary

The ChatGPT/Codex Chrome extension connects successfully to its Windows Native Messaging host, but browser control fails because the host-provided runtimeConfig does not contain the trustedBrowserClientSha256s field required by the extension.

The extension reports that the native Codex component is outdated. It may sometimes read the current tab, but navigation, clicking, and typing fail. Reinstalling the extension and the desktop Chrome plugin does not fix the problem.

I reproduced the same issue on two separate Windows computers using the same installation method.

Environment

• OS: Windows 11 Pro 25H2, build 26200.9168, x64
• Google Chrome: 151.0.7922.140, x64
• Chrome extension: ChatGPT 1.2.27259.19709
• Extension ID: hehggadaopoacecdllhhajmbjkdcmajg
• Windows package: OpenAI.Codex_26.814.5167.0_x64__2p2nqsd0c76g0
• Selected app version: 26.814.41407
• CLI version: 26.814.41407
• Native host version: 26.814.41407
• App server protocol version: 2
• Native host protocol version: 2
• Installation method on both affected PCs: direct/manual installation using the extension supplied through the ChatGPT/Codex setup, not a separately verified Chrome Web Store build

Actual behavior

The Chrome extension displays an error equivalent to:

The native Codex component for Chrome is outdated, so browser control is unavailable. Update or reinstall the Codex Chrome plugin.

Observed behavior:

• The current page can sometimes be read, but navigation, clicking, and typing fail.
• Sometimes a new about:blank tab opens and the extension session restarts.
• The selected Chrome tab or browser binding may then be reported as unavailable.
• Reinstalling and repairing the extension does not resolve the problem.

The user-facing error shown by the Chrome extension:
<img width="435" height="851" alt="Image" src="https://github.com/user-attachments/assets/5eecf018-eba8-4557-84f6-b50dd62a2beb" />

What steps can reproduce the bug?

1. Install the current ChatGPT/Codex Windows app.
2. Obtain the supplied ChatGPT Chrome extension package. The extension is not installed from the Chrome Web Store in this setup.
3. Open chrome://extensions, enable Developer mode, click Load unpacked, and select the unpacked extension directory containing manifest.json.
4. Confirm that Chrome shows extension ID hehggadaopoacecdllhhajmbjkdcmajg and version 1.2.27259.19709.
5. Enable the Chrome integration in ChatGPT/Codex and restart Chrome and the desktop app if requested.
6. Open a normal Chrome tab, for example https://example.com/.
7. Ask the Chrome side panel:

Open example.com, click Learn more, and report the new page title.

1. Observe that the extension reports an outdated or unsupported native component, opens about:blank, restarts, or fails before performing the click.
2. Remove and reinstall the unpacked extension and the desktop Chrome plugin, then repeat the test.

The problem persists after reinstalling and reproduces on two separate Windows computers using the same Developer mode installation method.

The desktop app still displays an “Install this extension in Chrome” prompt even though the unpacked extension is already installed and enabled:
<img width="700" height="1098" alt="Image" src="https://github.com/user-attachments/assets/89a98f17-44c0-46e1-9107-7b322b3d75b9" />

What is the expected behavior?

The Chrome extension and native host installed through the same ChatGPT/Codex setup should negotiate a compatible runtime configuration.

The extension should be able to:

• connect to the native host;
• read the current tab;
• navigate to a URL;
• click links and buttons;
• type into page elements;
• return the resulting page state.

If the extension and native host versions are incompatible, the setup flow should install compatible versions or report the exact missing field/version mismatch.

Additional information

1. Native Messaging registration and connection are working

The native host manifest exists at:

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

The Chrome Native Messaging registry key exists:

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

The registered host resolves to:

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

From the extension side-panel DevTools, this call succeeds:

await chrome.runtime.sendMessage({ type: "ensure_codex_app_server" })

The sanitized response reports:

{
  "ok": true,
  "nativeHostStatus": {
    "hostName": "com.openai.codexextension",
    "state": "connected"
  },
  "selected": {
    "appServerProtocolVersion": 2,
    "appVersion": "26.814.41407",
    "cliVersion": "26.814.41407",
    "nativeHostProtocolVersion": 2,
    "nativeHostVersion": "26.814.41407"
  }
}

This indicates that the failure is after Native Messaging connection, not a missing manifest or registry key.

2. The returned runtimeConfig is missing a field required by the extension

The native host response contains values including browserClientPath, browserPreference, codexCliPath, nodePath, nodeReplPath, and platform, but does not contain:

"trustedBrowserClientSha256s": ["..."]

Sanitized original response from the unmodified native host. Native Messaging is connected, but the returned runtimeConfig does not contain trustedBrowserClientSha256s:
<img width="917" height="702" alt="Image" src="https://github.com/user-attachments/assets/c8d71ef6-eb0f-4739-af27-7b42618cc4c5" />

The extension's side-panel runtime-config validator returns null for the actual response. If I add the missing field to an in-memory copy, the same validator accepts the object:

const response = await chrome.runtime.sendMessage({
  type: "ensure_codex_app_server"
});

// Extension validator result for response.runtimeConfig: null

const patchedConfig = {
  ...response.runtimeConfig,
  trustedBrowserClientSha256s: []
};

// The same validator now returns a valid runtime-config object.

An empty array only demonstrates the schema mismatch; it is not sufficient to establish trusted browser execution.

3. The installed browser client has a stable, computable hash

The selected client is:

%USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\latest\scripts\browser-client.mjs

Its SHA-256 on the affected installation is:

3B9D8DCC6DC968887E8A969C63DAE6380E3C1C59FF5C474EB32DF08C353DAD87

4. A diagnostic proxy confirms the missing hash is causal

As a diagnostic only, I placed a reversible local Native Messaging proxy in front of the official host. It forwards all length-prefixed Native Messaging frames unchanged, except that when runtimeConfig.trustedBrowserClientSha256s is absent it injects the SHA-256 of the selected browserClientPath.

With this injected value:

{
  "trustedBrowserClientSha256s": [
    "3B9D8DCC6DC968887E8A969C63DAE6380E3C1C59FF5C474EB32DF08C353DAD87"
  ]
}

the extension successfully navigated to a page and clicked a link. Without the injected field, the original “outdated native component” behavior returns.

This workaround is unsupported and is not proposed as a permanent solution; it was used only to isolate the compatibility failure.

Likely root cause

The Windows native host/app version 26.814.41407 and Chrome extension version 1.2.27259.19709 appear to use different runtimeConfig schemas:

• the extension requires trustedBrowserClientSha256s;
• the native host omits it;
• the extension therefore rejects a native host that is otherwise connected and reports it as outdated.

Because the same failure reproduced on two Windows computers, this appears to be a repeatable version/schema compatibility issue rather than corruption limited to one profile. Both reproductions used the same direct/manual extension installation method, so I have not established whether a separately distributed Chrome Web Store build avoids the issue.

Suggested fix

1. Ensure the native host always supplies trustedBrowserClientSha256s for every allowed browserClientPath.
2. Ship mutually compatible desktop/native-host and Chrome-extension versions atomically, or add explicit protocol/schema negotiation.
3. Report the missing field/version mismatch directly instead of the generic “outdated native component” message.
4. Add an integration test that installs the released Windows host and released Chrome extension together and verifies tab read, navigation, click, and typing.

Additional related observations

These may be separate bugs and are included only because they complicated diagnosis:

1. The bundled Windows native-host checker parsed the literal English registry value name (Default). On Russian Windows, reg query prints (По умолчанию), causing a false failure. Reading the first REG_* value instead made the checker return correct: true.
2. Desktop-side browser initialization also produced this separate Trusted RPC error until the exact browser scripts directory was added to the trusted code paths:

``text
Trusted RPC dependency must resolve within a configured trusted code path:
file:///%USERPROFILE%/.codex/plugins/cache/openai-bundled/browser/26.814.41407/scripts/browser-service.mjs
``

1. The desktop app rewrites the Native Messaging manifest path back to the official host at startup. This is expected for self-repair, but it means the diagnostic proxy had to monitor and restore its reversible manifest override while testing.

The primary issue in this report is the missing trustedBrowserClientSha256s field and the resulting extension/native-host incompatibility.

Related reports

• #21781 — Windows browser client is not trusted although Chrome/native-host checks pass
• #25247 — Browser plugin bootstrap fails because the browser client is not trusted
• #23884 — Chrome plugin still lacks a trusted native-pipe/browser-client surface after reinstall
• #21674 — Windows native-host checker/localized (Default) registry parsing
• #22849 — Chrome opens but browser-control session cannot navigate/click/type
• #31769 — Chrome extension connected/installed but browser backend unavailable

Privacy note

I have intentionally removed local WebSocket tokens, account identifiers, session IDs, and full user-specific paths. I can provide additional sanitized logs if a maintainer specifies which component or event-log channel is needed.