[Windows] Chrome extension fails to start: app-server manifest missing required nodePath after Codex data-directory migration #41592

Activity

1. tylerdavisop-hue

   added

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

   on Aug 30, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   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

   browser

   on Aug 30, 2026
3. github-actions commented on Aug 30, 2026

   

   github-actionsBot

   on Aug 30, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • [Windows] Chrome plugin clean reinstall leaves stale chrome-native-hosts-v2 entries and fails with missing codexCliPath #40357

   Powered by Codex Action
4. zemeng5208 commented on Aug 30, 2026

   

   zemeng5208

   on Aug 30, 2026 – with ChatGPT Codex Connector

   More actions

   This looks like a high-confidence local Chrome bridge state mismatch rather than a generic browser-policy or account issue.

   I maintain WinBridge Recovery: https://github.com/zemeng5208/winbridge-recovery

   In this specific case, the useful local repair scope is the Windows Chrome integration state around:

   • the versioned chrome plugin cache and its latest target;
   • com.openai.codexextension.json plus the HKCU Native Messaging Host registration;
   • chrome-native-hosts-v2.json / app-server host metadata;
   • extension-host-config.json and the nodePath / resourcesPath values consumed by the extension host.

   The strongest signal here is that the generated native host still launches from D:\CodexDataClean\.codex\...\chrome\latest\..., while the active Codex state is under a different migrated .codex tree, and extension-host-config.json is missing. WinBridge can help diagnose that divergence, stop the owned extension-host process, validate which cache/version is actually complete, and rebuild the user-side host/registry/config state so those paths agree again.

   A limitation: it does not modify WindowsApps, bypass package protection, or guarantee a fix. If the cache, latest, Native Host manifest/registry, v2 state and extension-host config are all regenerated consistently for the current install but Codex 26.825.41651 still omits nodePath, that would point to an upstream Desktop/native-host generation regression rather than repairable stale local state.
5. yilin06415-cmd commented on Aug 30, 2026

   

   yilin06415-cmd

   on Aug 30, 2026 – with ChatGPT Codex Connector

   More actions

   Additional verified reproduction on Windows Desktop 26.825.6671 / Codex CLI 0.151.0-alpha.7.2:

   After repairing the native-host manifest and rebuilding the current Chrome and Browser plugin caches from the bundled app resources, static validation passed:

   • native messaging manifest and registry entry are correct;
   • extension-host-config.json contains existing nodePath, nodeReplPath, codexCliPath, and browserClientPath values;
   • Chrome successfully relaunches extension-host.exe.

   The remaining browser bootstrap still fails before Chrome discovery. The trusted browser runtime attempts to lstat the default Codex home path and returns:

   EPERM: operation not permitted, lstat 'C:\Users\<redacted>\.codex'
   

   On this machine that default path is a Windows directory junction to a physical Codex home on another volume. Direct lstat of the physical target succeeds, and normal directories under C:\Users<redacted> also succeed. The failure is specifically the valid relocated-home junction at the default .codex root.

   User impact: Chrome control is unavailable even after reinstall/restart/manifest repair, which blocks work that depends on an already signed-in browser. A full migration back to C: is not a practical workaround when the Codex home is larger than available C: space.

   Requested product fixes:

   1. Resolve and safely validate a Codex-home junction/reparse target rather than rejecting it during browser bootstrap.
   2. Treat the desktop update, plugin cache, native-host config, and app-server manifest as one self-healing transaction.
   3. Surface an actionable diagnostic that identifies the rejected home-directory junction instead of reporting only a missing runtime path.
   4. Provide a supported in-app repair/migration flow that preserves existing data and does not require manual cache or manifest work.

   No account data, credentials, session contents, or user-specific paths are included here.
6. th3nolo commented on Aug 30, 2026

   

   th3nolo

   on Aug 30, 2026

   More actions

   Independent reproduction on a normal Microsoft Store installation, without moving the Codex data directory.

   As of 2026-08-30, this still occurs with:

   • Codex AppX package 26.825.6671.0
   • ChatGPT Chrome extension 1.2.27268.51612
   • Chrome extension installed and enabled in the active profile

   The exact user-facing error is:

   Codex app-server manifest entry is missing required path nodePath
   

   Read-only host diagnostics point to an update/bootstrap reconciliation failure rather than a bad Chrome extension:

   • The Chrome native-host registry entry and com.openai.codexextension.json both exist and are structurally valid.
   • %LOCALAPPDATA%\OpenAI\Codex\chrome-native-hosts-v2.json contains 23 historical entries and was last modified on 2026-08-23. Every entry has a paths.nodePath property, but the recent targets no longer exist, and there is no current 26.825 registration.
   • A current CUA Node runtime does exist at %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\415ffebf3d576e9b\bin\node.exe; it simply was not reconciled into the app-server manifest.
   • The bundled source advertises Browser/Chrome 26.825.51511, while the installed cache still has Browser 26.727.40816 and Chrome 26.825.32147. Importing the expected Browser service consequently fails because the 26.825.51511 cache path is absent.
   • The configured openai-bundled marketplace source is also WSL-shaped (/mnt/c/Users/<user>/...) although the active CLI is Windows-native. A one-command read-only override to the equivalent Windows path makes the marketplace appear immediately.

   Updating all Store apps, restarting several times, reinstalling the Chrome extension, and reinstalling through Settings > Computer Use did not fix it.

   This suggests that the data-directory migration in this report can expose the bug, but is not required to reproduce it. The failing chain is the Store update/bootstrap not atomically reconciling the bundled marketplace registration, versioned plugin cache, and app-server/native-host runtime registrations.
7. andrewchan534 commented on Aug 31, 2026

   

   andrewchan534

   on Aug 31, 2026 – with ChatGPT Codex Connector

   More actions

   Additional reproduction after a normal Desktop App update.

   This machine previously had the Chrome integration working normally after the native-host state was repaired. After the Desktop App updated again, the integration immediately broke again with:

   Unable to start ChatGPT
   Codex app-server manifest entry is missing required path nodePath
   

   Current environment:

   • AppX: OpenAI.Codex 26.825.6671.0
   • Current CUA Node runtime exists at:
     %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\415ffebf3d576e9b\bin\node.exe
   • chrome-native-hosts-v2.json still has its latest entry at 26.814.41407
   • That entry references the previous runtime:
     ...\cua_node\f24ab376120677c2\bin\node.exe
   • Test-Path for that recorded nodePath returns False
   • resourcesPath in the same entry is also stale and returns False
   • The current Node runtime itself is present and contains both node.exe and node_repl.exe

   The important part in this reproduction is that no Codex data-directory migration occurred between the working and broken states. The browser integration was working, then a normal Desktop App update replaced the CUA Node runtime without reconciling the app-server/native-host registration.

   This makes manual repair after every Desktop App update necessary, which is not a sustainable workaround.

   It appears the Desktop updater should atomically refresh or self-heal the Chrome/native-host app-server registration whenever its bundled runtime changes.
8. tylerdavisop-hue

   closed this as completedon Aug 31, 2026
9. fricpa commented on Sep 27, 2026

   

   fricpa

   on Sep 27, 2026

   More actions

   This keeps happening.

   

   if a reinstall is needed that's a shame for anyone not technical enough to realize this and the fix definitely should have been provided as a migration on an update if at all possible...