Windows: Chrome plugin install fails to create com.openai.codexextension Native Messaging Host #28950

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

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

   skillsIssues related to skillsIssues related to skills

   browser

   on Jun 18, 2026
2. github-actions commented on Jun 18, 2026

   

   github-actionsBot

   on Jun 18, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Chrome extension #28880
   • Browser / Google Chrome plugins are removed on Codex startup after successful UI Install #28703

   Powered by Codex Action
3. tangtangsky0605 commented on Jul 14, 2026

   

   tangtangsky0605

   on Jul 14, 2026

   More actions

   你解决这个问题了吗，我也遇到同样的问题
4. guzemres-ai commented on Jul 17, 2026

   

   guzemres-ai

   on Jul 17, 2026 – with ChatGPT Codex Connector

   More actions

   Reproduced on a newer Codex Desktop build. This appears to be the same failure mode as the original report.

   Environment

   • Windows 10 Home, version 10.0.19045, x64
   • Codex Desktop package: OpenAI.Codex 26.715.2305.0
   • Chrome: 150.0.7871.125
   • Chrome plugin: chrome@openai-bundled 26.601.21317
   • Chrome extension ID: hehggadaopoacecdllhhajmbjkdcmajg
   • Chrome extension version: 1.2.27221.15725_0
   • Chrome profile: Default

   Observed state

   The Chrome extension diagnostic succeeds:

   installed=true
   enabled=true
   registered=true
   selectedProfileDirectory=Default
   

   The plugin UI initially displays Failed to install plugin, but the Chrome plugin can later appear in the installed/enabled list. Despite that, the required Native Messaging Host remains completely absent:

   %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json
   missing
   
   HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension
   missing
   

   check-native-host-manifest.js --json reports:

   exists=false
   correct=false
   registryManifestPath=null
   Windows native host registry key does not exist
   Native host manifest does not exist
   

   The ChatGPT Chrome side panel therefore continues to show:

   Install the app to use ChatGPT in Chrome
   

   Troubleshooting completed

   • Updated Codex Desktop.
   • Removed and re-added the Chrome plugin.
   • Removed and reinstalled the Chrome extension.
   • Closed and restarted all Chrome windows.
   • Fully restarted Codex Desktop.
   • Repeated the extension and native-host diagnostics after restart.
   • Confirmed the extension is installed in the active Chrome profile.
   • Confirmed the manifest was not mistakenly written to the Codex sandbox user profile or the Windows system profile.
   • Confirmed the target %LOCALAPPDATA%\OpenAI\extension directory exists and the interactive Windows user has Full Control.

   The plugin package copy appears to succeed, but the native-host setup step does not run or fails without rolling back the installed/enabled plugin state.

   A desktop-app feedback report was also submitted with ID:

   no-active-thread-019f71aa-ce8a-79d1-a822-1842469a56e2

   This confirms the issue is still reproducible in Desktop 26.715.2305.0 with extension 1.2.27221.15725_0.
5. FeyZha commented on Jul 18, 2026

   

   FeyZha

   on Jul 18, 2026 – with ChatGPT Codex Connector

   More actions

   Confirmed on Codex Desktop 26.715.4045.0 with Chrome plugin 26.715.31925 and extension 1.2.27221.15725_0.

   In my reproduction this was not a Chrome-extension problem. The WindowsApps runtime and bundled marketplace files were Archive, Encrypted / application-protected, and Electron/Node copying failed with Windows error 6000. The plugin then appeared installed/enabled, but native-host reconciliation never produced the manifest, HKCU key, v2 state, or latest junction.

   A second important finding: a successful

   codex plugin add chrome@openai-bundled
   

   only installs the plugin payload. It does not by itself execute the desktop host service that creates/reconciles the Chrome native host, so CLI success is not proof that the browser integration is healthy.

   The recovery was:

   1. Close Chrome and plugin-owned host/diagnostic processes.
   2. Copy the four official signed runtime executables into the exact cache directory expected by the current build with decrypted-destination semantics such as robocopy /COPY:DT.
   3. Verify source/destination byte size, SHA-256, and Authenticode.
   4. Mirror the bundled openai-bundled marketplace to a stable user-writable path using the same semantics and verify the complete tree.
   5. Re-add the plugin through the supported flow, then let the desktop app perform its own native-host reconciliation.
   6. Verify latest, .plugin-appserver, chrome-native-hosts-v2.json, the manifest, and the HKCU key before testing the real extension backend.

   Do not manually fabricate the native manifest/registry and do not run installManifest.mjs.

   After repair, I verified the real Chrome extension backend end-to-end by opening https://example.com/ and reading the title and DOM successfully.

   Full root-cause and lifecycle detail is also posted in #32802.
6. guzemres-ai commented on Jul 22, 2026

   

   guzemres-ai

   on Jul 22, 2026 – with ChatGPT Codex Connector

   Last edited by guzemres-ai

   More actions

   Follow-up from the same Windows machine: the native host/side panel was recovered, but Chrome control still failed at the browser runtime bootstrap stage because Codex Desktop was pointing to a stale extracted CUA runtime.

   Current environment

   • Codex Desktop package: OpenAI.Codex 26.715.9868.0
   • Codex CLI: 0.145.0-alpha.30
   • Chrome plugin: chrome@openai-bundled 26.715.72028
   • Chrome extension: 1.2.27221.15725

   After the side panel connected successfully, a new Chrome-backed task ("open example.com in a new tab") failed with:

   Mcp error: -32602: js: codex/sandbox-state-meta: missing field `sandboxPolicy`
   

   The plugin's extension-host-config.json and the v2 native-host state both referenced:

   %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\a89897d3d9baa117\bin\node_repl.exe
   

   That cached runtime was stale:

   runtime_archive_version: 0.0.1/20260609232601-73ffe8b8261e
   node_repl_archive_path: 20260609.1/node_repl-20260609.1-x86_64-pc-windows-msvc.zip
   node_repl.exe size: 13,513,728 bytes
   

   The current Desktop package contains a newer runtime:

   runtime_archive_version: 0.0.4/20260713191736-ad8b1874340f-pr-1124580
   node_repl_archive_path: 20260713.2/node_repl-20260713.2-x86_64-pc-windows-msvc.zip
   node_repl.exe size: 14,280,704 bytes
   

   As a diagnostic workaround, I backed up the cached executable and replaced only node_repl.exe with the exact file from the current installed package. The destination SHA-256 was verified against the package source:

   5419A4DBA576A319EB33D848131ACECA62AC189224211C84C0ECD932A8310CB8
   

   After that replacement, the same browser task progressed past runtime bootstrap, performed the browser navigation policy check, and successfully opened https://example.com/ in a new Chrome tab.

   A normal recursive copy from WindowsApps again failed with Windows error 6000 / "The specified file could not be encrypted"; a byte-for-byte destination write was required. The old executable remains backed up.

   This suggests that a Codex Desktop update can leave the extracted cua_node runtime at 0.0.1 while the updated app/plugin continues referencing that stale cache directory. The app should invalidate or re-extract this runtime based on its manifest version/hash during update or Chrome-plugin reconciliation. This is related to the encrypted-package copy failure already described above and in #32802.

   Desktop feedback report

   A Codex Desktop feedback report with logs was submitted with ID:

   019f71ba-3bc1-7de0-8c92-7d10a96bcbc2
7. guzemres-ai commented on Jul 22, 2026

   

   guzemres-ai

   on Jul 22, 2026 – with ChatGPT Codex Connector

   More actions

   Follow-up: Chrome control works in the Chrome side panel, but not from Codex Desktop tasks

   This is an important correction to my previous successful test: opening https://example.com/ confirmed URL navigation only. It did not confirm element-level page interaction from a Codex Desktop task.

   Environment

   • Windows
   • Codex Desktop: 26.715.9868.0
   • Chrome plugin: 26.715.72028
   • Chrome extension: 1.2.27221.15725

   Reproduction

   1. Created a fresh Codex Desktop task after the Chrome plugin and extension were installed and connected.

   2. With a web application open in Chrome, explicitly invoked @Chrome and asked the Desktop task only to confirm that it could see the current tab, without making changes.

   3. The fresh Desktop task failed with the equivalent of:

      Could not connect to the current Chrome tab, so I cannot confirm that I can see the page. No changes were made.

   4. In the ChatGPT side panel inside the same Chrome tab, asked it to identify visible page content without editing.

   5. The side panel correctly read the visible content.

   6. As a safe interaction test, asked it to collapse and immediately expand an existing UI layer. It completed the action successfully, and the user directly observed both UI actions. No document content was modified.

   Conclusion

   The Chrome extension, native host, page reading, and element-level UI interaction are working from the Chrome side panel. The remaining failure is specifically the handoff/connection between a Codex Desktop task and the active Chrome tab.

   Starting a fresh Desktop task does not clear the problem, so this is not only stale chat-specific state. The issue should not yet be considered fully resolved.

   Related feedback ID: 019f71ba-3bc1-7de0-8c92-7d10a96bcbc2
8. olet commented on Jul 26, 2026

   

   olet

   on Jul 26, 2026 – with ChatGPT Codex Connector

   More actions

   Additional reproduction on a current Windows build (2026-07-26).

   Environment:

   • Codex Desktop Microsoft Store package: OpenAI.Codex_26.721.4979.0_x64
   • Codex CLI used by the active app session: 0.125.0
   • Windows x64
   • Google Chrome: 150.0.7871.182
   • Official Chrome extension installed and enabled
   • chrome@openai-bundled shown as installed/enabled in Codex

   After fully restarting Codex and Chrome, then reinstalling both the Codex Chrome plugin and the Chrome extension, the UI still showed Chrome as connected, but agent-side Chrome discovery failed.

   The installed state matched this issue exactly:

   %LOCALAPPDATA%\OpenAI\Codex\chrome-native-hosts-v2.json
   {"schemaVersion":2,"entries":[]}
   
   %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json
   missing
   
   HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension
   missing
   

   There were two additional broken installation artifacts:

   1. %USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\latest was missing, while only chrome\local existed. installManifest.mjs resolves a cache install to ..\latest, so the native-host install path could not complete normally.
   2. The installed Chrome bundle also lacked its packaged docs directory, so after the runtime finally connected, browser.documentation() failed with Packaged browser documentation directory is missing.

   The bundled browser-client.mjs then independently failed at bootstrap with:

   Cannot redefine property: process
   

   This is the same runtime incompatibility reported in #34372 (also related to #33001 / #32991). Reinstalling the plugin restored the same stale/incompatible artifact, so restart and reinstall did not help.

   A local repair confirmed all layers:

   1. Created a non-destructive chrome\latest junction pointing to chrome\local.
   2. Kept the process shim module-local instead of assigning to the protected globalThis.process.
   3. Restored the missing packaged browser API docs from the bundled Browser plugin.
   4. Ran the official installManifest.mjs with the current Codex app runtime paths.
   5. Verified check-native-host-manifest.js --json returned correct: true and the expected extension origin.
   6. Re-ran backend discovery: it changed from extension: 0 to extension: 1.
   7. Successfully listed the user's open Chrome tabs through the official extension backend.

   This suggests the Windows Chrome plugin install/repair flow should be atomic and validate all of the following before reporting installed/connected:

   • latest points to the active plugin payload;
   • the native-host manifest exists;
   • the HKCU NativeMessagingHosts registration points to that manifest;
   • required packaged docs exist;
   • the bundled client can initialize inside the current trusted runtime.

   If any check fails, the installer should repair it or surface the exact failing step instead of leaving the plugin marked installed/enabled and the UI showing a misleading connected state.
9. Shallow-dusty commented on Jul 27, 2026

   

   Shallow-dusty

   on Jul 27, 2026 – with ChatGPT Codex Connector

   More actions

   Additional current-build reproduction (2026-07-27):

   • Codex Desktop Microsoft Store package: 26.721.4979.0
   • Chrome plugin: chrome@openai-bundled 26.721.41059
   • Chrome extension: 1.2.27221.15725_0
   • Chrome profile: Default

   The plugin is installed/enabled and the official extension diagnostic reports the extension installed, registered, and enabled. However, the native-host installation is only partially present:

   %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json
   exists
   
   HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension
   missing
   

   The official native-host manifest check exits with code 1, reports correct=false, and specifically identifies the missing registry key. After fully restarting Codex and Chrome, the Chrome side panel still says Install the app to use ChatGPT in Chrome / open the app if already installed, and browser-backend discovery exposes only the in-app browser (iab), not the Chrome extension backend.

   No manifest or registry entry was manually created or edited for this verification.

   This is a slightly different partial-install state from the original both-missing case: the manifest file exists, but registration did not complete. The installer/repair flow should validate the manifest, the HKCU registration, and real extension-backend discovery before reporting the plugin as installed/enabled or connected; otherwise it should repair the missing step or surface it explicitly.
10. BogdanAlinG commented on Jul 27, 2026

    

    BogdanAlinG

    on Jul 27, 2026 – with ChatGPT Codex Connector

    More actions

    Follow-up: packaged desktop detector ignores isolated Chrome profiles, and native-host reconciliation does not enforce the registry postcondition

    Additional read-only diagnosis on the current Windows ARM64 build (2026-07-27), extending the current-build reproduction already reported above.

    Environment

    • Codex Desktop Microsoft Store package: 26.721.4979.0
    • Chrome plugin: chrome@openai-bundled 26.721.41059
    • Chrome extension: 1.2.27221.15725_0
    • Extension ID: hehggadaopoacecdllhhajmbjkdcmajg
    • Chrome uses an isolated profile root under %USERPROFILE%\.codex\chrome-profiles\<scope>

    Confirmed profile-detection mismatch

    Running the bundled extension diagnostic without overrides selects:

    %LOCALAPPDATA%\Google\Chrome\User Data\Default
    installed=false
    enabled=false
    exitCode=2
    

    Running the same diagnostic with CODEX_CHROME_USER_DATA_DIR and CODEX_CHROME_PREFERENCES_PATH set to the isolated profile reports:

    selectedProfileDirectory=Default
    installed=true
    enabled=true
    exitCode=0
    extensionVersion=1.2.27221.15725_0
    

    Packaged-code inspection explains the mismatch:

    • The desktop sync detector scans only %LOCALAPPDATA%\Google\Chrome\User Data\<profile>\Extensions\<extensionId>.
    • Its caller supplies only the extension ID; it does not use CODEX_CHROME_USER_DATA_DIR or CODEX_CHROME_PREFERENCES_PATH.
    • The bundled plugin's own check-extension-installed.js and open-chrome-window.js do honor those overrides.

    This creates two different answers inside the same shipped product: the plugin diagnostic sees the active isolated profile, while Desktop reconciliation concludes that the extension is absent.

    Lifecycle evidence

    Startup logs show the consequence:

    1. When the plugin was sync-managed, Desktop logged isExtensionInstalled=false, selected uninstall_managed, uninstalled the plugin, and removed native-host state.
    2. After the plugin was reinstalled through the UI, the managed marker was absent. Desktop logged keep_user_managed with isExtensionInstalled=false.
    3. With the plugin current, native-host reconciliation completed without a visible error, but the required state remained:

    %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json
    exists
    
    HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension
    missing
    

    The official native-host checker exits 1 and reports correct=false. Extension-backed discovery remains unavailable.

    The packaged Windows registration path invokes reg add for the HKCU key, but does not query the value afterward and compare it with the expected manifest path. Therefore reconciliation can finish without enforcing the required postcondition.

    Suggested durable fix

    1. Use the bundled profile-aware detector in Desktop reconciliation, or pass the configured/active Chrome profile roots through the desktop detector.
    2. Treat the extension as present if it exists in any configured isolated root; do not infer global removal from only the normal Default profile.
    3. After native-host registration, query the HKCU value and compare it with the expected manifest path. Fail reconciliation visibly if it is absent or wrong.
    4. Add Windows regression coverage for:
       • extension installed only in a custom profile root;
       • current user-managed plugin repairing a missing registry key;
       • managed cleanup removing only cache-owned native-host state.

    No registry entries, manifests, app-package files, or plugin-cache files were manually changed during this diagnosis.

    Related Codex task ID: 019fa2b2-be95-71e3-ba4e-aa9d80af56a3
11. arkuszzhu-maker commented on Aug 6, 2026

    

    arkuszzhu-maker

    on Aug 6, 2026 – with ChatGPT Codex Connector

    Last edited by arkuszzhu-maker

    More actions

    Update withdrawn. The local Chrome integration issue has been resolved after moving the Microsoft Store Codex/ChatGPT app package from a secondary AppX volume to the Windows system drive and reinstalling the bundled Chrome plugin. The original issue was created by another user; this comment was only an additional reproduction report.
12. zemeng5208 commented on Aug 12, 2026

    

    zemeng5208

    on Aug 12, 2026 – with ChatGPT Codex Connector

    More actions

    Disclosure: I’m the author/maintainer of WinBridge Recovery, an independent Windows recovery utility for Codex Desktop.

    The inconsistent state described here — Chrome plugin installed/enabled, extension present, but the Native Messaging manifest/registry entry and chrome-native-hosts-v2.json not materialized correctly — overlaps directly with the native-host registration checks in the project.

    The tool discovers the currently installed official Codex package and user-side plugin cache, backs up the existing configuration/registration state, validates the expected host executable and paths, and repairs local registration/pointer drift when it can derive the correct values from the installed official files. It does not fabricate a third-party host binary and does not modify WindowsApps.

    This still shouldn’t be treated as an upstream installer fix: if the current Codex build itself refuses to provision the host for a product/entitlement reason, the tool cannot change that. But for a partial-install state where the official plugin files exist and only the user-side native-host registration is missing/stale, this is one of the scenarios WinBridge Recovery is intended to recover.
13. Laily6026 commented on Aug 20, 2026

    

    Laily6026

    on Aug 20, 2026

    More actions

    I can reproduce this issue on Windows.

    Feedback ID: 01a01793-5f01-7702-b077-043a4ca445c2

    Environment

    • Codex Chrome plugin version: 26.814.41407
    • Codex Chrome extension version: 1.2.27259.19709_0
    • Chrome profile: Default
    • The official Codex Chrome extension is installed and enabled.

    Observed behavior

    The extension is detected as installed and enabled, but the following Native Messaging Host components are both missing:

    • Registry key:
      HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension
    • Manifest:
      %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json

    Chrome control also fails during initialization with the following error:

    Trusted RPC dependency must resolve within a configured trusted code path:
    file:///C:/Users/sgh98/.codex/plugins/cache/openai-bundled/browser/26.814.41407/scripts/browser-service.mjs

    I reinstalled the Codex Chrome plugin three times and also tested it in newly created Codex chats, but the same failure persists.
    This appears to involve both the missing Native Messaging Host registration described in this issue and a trusted plugin-path/runtime initialization problem similar to #21781 and #23414.
14. Pacifist-5 commented on Sep 13, 2026

    

    Pacifist-5

    on Sep 13, 2026 – with ChatGPT Codex Connector

    More actions

    I can reproduce this on a newer Windows desktop build.

    Environment

    • Windows 10 Pro 22H2, build 19045, x64
    • ChatGPT/Codex Desktop: OpenAI.Codex 26.908.4834.0
    • Codex CLI: 0.154.0-alpha.6.2
    • Chrome extension ID: hehggadaopoacecdllhhajmbjkdcmajg
    • Chrome extension version: 1.26.901.11451_0
    • Chrome profile: Default

    Observed state

    The Chrome extension checker succeeds: the extension is installed, registered, and enabled. Settings → Computer use shows Google Chrome as installed/Manage with its toggle enabled. However, the @ menu exposes only Computer and the in-app Browser, and agent.browsers.get("chrome") returns Browser is not available: chrome.

    The native host checker still reports both components missing:

    %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json
    HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension
    

    No extension-host.exe process starts.

    Troubleshooting performed

    • Reinstalled the official Chrome extension.
    • Ran the Microsoft-signed ChatGPT Installer.
    • Restarted Chrome and ChatGPT/Codex Desktop multiple times.
    • Removed ChatGPT Classic so only the current OpenAI.Codex package remains.
    • Confirmed the extension is enabled in the active Chrome profile.
    • Checked HKCU, HKLM, and WOW6432Node native-messaging registry locations.

    There was also a separate bundled-marketplace startup failure in this installation: Codex logged UNKNOWN: unknown error, copyfile while copying the application-protected MSIX file plugins/sites/.app.json. After restoring and SHA-256 verifying all 952 official bundled-marketplace files, the marketplace copy error disappeared and the Browser/Chrome skills became available, but the Chrome native host manifest and registry key were still never created.

    Diagnostic logs were uploaded through /feedback.

    Uploaded thread ID: 01a098d5-13fd-7f71-9577-dd4ca616d006

    This indicates the native-host installation failure is still present in desktop build 26.908.4834.0.
15. VaLeXaR commented on Oct 2, 2026

    

    VaLeXaR

    on Oct 2, 2026

    More actions

    Reproduced on a newer Windows desktop build with an additional installation-path finding.
    Environment:

    • ChatGPT / Codex Desktop package: OpenAI.Codex 26.930.2377.0
    • Windows x64
    • Browser: Microsoft Edge
    • Edge profile: Default
    • Edge extension ID: odlomjlbamekndcpllcnffbgeohgkmjh

    The Edge extension diagnostic succeeds:

    selectedProfileDirectory: Default
    installed: true
    enabled: true
    exitCode: 0
    

    Native-host diagnostics still fail:

    manifestPath:
    %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json
    
    registryKey:
    HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension
    
    exists: false
    correct: false
    

    Both the manifest and registry key remain missing after reinstalling/updating the desktop application.
    I also checked filesystem access:

    • The bundled extension-host.exe exists under the AppX package.
    • It can be read and copied successfully out of WindowsApps.
    • %LOCALAPPDATA%\OpenAI\extension is writable.
    • The user plugin cache exists, but no Chrome native-host payload is materialized there.
      Additional finding in build 26.930.2377.0:
      The bundled installManifest.mjs constructs extension-host-config.json using the directory of extensionHostPath, effectively:
      dirname(extensionHostPath) + extension-host-config.json

    On this installation, extensionHostPath resolves to:

    C:\Program Files\WindowsApps\OpenAI.Codex_26.930.2377.0_x64__2p2nqsd0c76g0\
    app\resources\plugins\openai-bundled\plugins\chrome\
    extension-host\windows\x64\extension-host.exe
    

    A direct write test to that directory fails:

    WRITE TO WINDOWSAPPS: FAILED
    Access to the path
    'C:\Program Files\WindowsApps\OpenAI.Codex_26.930.2377.0_x64__2p2nqsd0c76g0\...\chatgpt-write-test.tmp'
    is denied.
    

    At the same time, writing to:
    %LOCALAPPDATA%\OpenAI\extension

    succeeds.
    This suggests that the native-host provisioning path may be attempting to create extension-host-config.json next to the packaged extension-host.exe inside the read-only AppX package directory, and aborting before it creates:
    %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json
    HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension

    This is still reproducible on 26.930.2377.0.

    I can provide the full redacted output of check-extension-installed.js --browser edge --json and check-native-host-manifest.js --browser edge --json if useful.
16. nsawa0323 commented on Oct 4, 2026

    

    nsawa0323

    on Oct 4, 2026

    More actions

    I am seeing what appears to be the same issue on Windows.

    Environment:

    • Windows: 10.0.26200.9457
    • ChatGPT desktop app: 26.930.3930.0
    • Subscription: Plus
    • App source: Microsoft Store
    • Chrome extension ID: hehggadaopoacecdllhhajmbjkdcmajg

    Symptoms:

    • Chrome: "Install the app to use ChatGPT in Chrome"
    • Edge: "Native transport disconnected"
    • Brave: "Install the app to use ChatGPT in Brave Browser"
    • Settings > Computer Use shows Chrome and Edge as installed and Manage is available.

    Native host diagnostics:

    • where codex-chrome-native-host.exe returns exactly one path:
      C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\codex-chrome-native-host.exe
    • %LOCALAPPDATA%\OpenAI\extension\ does not exist at all (FOLDER_NOT_FOUND)
    • Therefore this manifest is also missing:
      %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json
    • This registry key is missing:
      HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension

    The bundled ChatGPT app files contain installManifest.mjs and
    check-native-host-manifest.js, and the bundled configuration specifies:
    extensionHostName: "com.openai.codexextension".

    Troubleshooting already completed:

    • Updated ChatGPT desktop app
    • Repair/reset
    • Uninstalled and reinstalled ChatGPT from Microsoft Store
    • Reinstalled the browser extension via Settings > Computer Use > Manage
    • Tested Chrome, Edge, and Brave
    • Completely removed McAfee WebAdvisor
    • Temporarily disabled ESET Web Access Protection and HTTPS traffic inspection
    • Tested using mobile tethering instead of the normal network
    • Rebooted Windows and retested

    The behavior is unchanged in all cases.

    I have NOT manually created or modified the native-host manifest or registry.

    Feedback/session ID shared with OpenAI Support and available to maintainers if needed.