Windows Codex Desktop: Chrome integration installed but chrome-native-hosts-v2.json is never created; stale latest junction after update #42520

Activity

1. ee0319-collab

   added

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

   on Sep 3, 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

   browser

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

   on Sep 3, 2026
3. github-actions commented on Sep 3, 2026

   

   github-actionsBot

   on Sep 3, 2026 – with GitHub Actions

   Contributor

   More actions

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

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

   Powered by Codex Action
4. PracticalSwan commented on Sep 4, 2026

   

   PracticalSwan

   on Sep 4, 2026 – with ChatGPT Codex Connector

   More actions

   Additional Windows detection evidence on a newer build, separate from the Chrome-registration portion of this issue:

   • Desktop package: OpenAI.Codex 26.901.4073.0
   • Bundled CLI: codex-cli 0.153.1
   • After a verified full Desktop restart, the packaged app had 10 live ChatGPT.exe processes under the current AppX package, all created by the new launch.
   • In the same state, bundled codex doctor exited 0 but reported Desktop App -> the desktop application is not running.
   • The package itself reports Status=Ok, and the process inventory confirms the app is running; the separate VS Code Codex process was excluded from that count.

   So the Windows running: false / desktop application is not running detection issue mentioned in the report still reproduces on 26.901.4073.0 / CLI 0.153.1.
5. svshi-gang commented on Sep 6, 2026

   

   svshi-gang

   on Sep 6, 2026

   More actions

   Title: Possible Windows EFS interaction causing ChatGPT/Codex Chrome native-host failures

   I’ve been fighting the current Windows ChatGPT/Codex Chrome integration issue for days.

   My symptoms included:

   Chrome integration unavailable / greyed out
   extension saying the desktop app needed to be installed even though it already was
   “in-app browser plugin unavailable”
   missing/stale native messaging registration
   stale or incomplete chrome-native-hosts-v2.json
   browser runtime/plugin components failing to provision cleanly
   repeated repairs/reinstalls not fixing the underlying issue

   While debugging it, I noticed something completely separate: Windows had recently started showing EFS UI Application notifications asking me to back up a file-encryption certificate.

   I had never intentionally enabled EFS and had never seen those notifications before.

   I checked:

   fsutil behavior query disableencryption

   and got:

   DisableEncryption = 0 (Encryption is ENABLED)

   Then I ran:

   cipher /u /n /h

   and found EFS-encrypted files not just in WindowsApps, but also in writable Codex browser/runtime data under paths like:

   C:\Users<user>\AppData\Roaming\Codex\web\Codex\Default...

   including Chromium/LevelDB state, local storage, extension state, partition data, etc.

   I also checked my EFS certificate with:

   cipher /y

   Windows had generated a new self-signed EFS certificate only a few days earlier, despite me never intentionally turning EFS on.

   I then:

   moved Codex back onto the system drive
   decrypted the affected user/runtime files
   rescanned with:
   cipher /u /n /h
   confirmed that normal user/Codex paths were no longer showing as EFS-encrypted
   left WindowsApps, WpSystem, and package-managed files alone
   disabled future EFS encryption with:
   fsutil behavior set disableencryption 1

   then rebooted

   After that, the ChatGPT Chrome side panel started working.

   I want to be very clear: I am not claiming EFS is definitely the root cause of every current Chrome/native-host failure.

   But on my machine, the broken Chrome integration and unexpected EFS activation overlapped, writable Codex browser state was being encrypted, and the integration began working after I removed that condition and normalized the install/runtime location.

   If you’re seeing the current Windows native-host / Chrome integration failures, I think it’s worth checking this before reinstalling Codex for the twentieth time.

   Read-only checks:

   fsutil behavior query disableencryption
   cipher /u /n /h
   cipher /y

   Things that would get my attention:

   C:\Users<user>\AppData\Roaming\Codex
   C:\Users<user>.codex
   C:\Users<user>.cache\codex-runtimes
   normal Desktop/Documents/project folders

   Things I would not manually decrypt or take ownership of just because they appear in the scan:

   C:\Program Files\WindowsApps
   :\WindowsApps
   WpSystem
   $RECYCLE.BIN
   AppData\Local\Packages

   Also, if you do find unexpected EFS encryption, back up the EFS certificate/private key before decrypting anything and do not delete that certificate until you are sure no files still depend on it.

   This may be unrelated on some machines, but given how many current Windows reports involve broken native-host provisioning, stale runtime state, and missing bridge files, I think the EFS angle is worth ruling out.
6. pinuocao-c commented on Sep 9, 2026

   

   pinuocao-c

   on Sep 9, 2026 – with ChatGPT Codex Connector

   More actions

   I can independently reproduce this on Windows with Codex Desktop AppX 26.901.6511.0, Chrome 152.0.7977.77, and the ChatGPT Chrome extension 1.26.901.11451.

   Observed behavior:

   • Codex Settings > Computer Use reports Chrome as installed/enabled and shows Manage.
   • The Chrome side panel consistently reports: No compatible Codex app-server entry was found.
   • Removing/reinstalling the Chrome Web Store extension, restarting Chrome/Codex, and using Windows Repair for the desktop app did not resolve it.
   • The installed desktop CLI is codex-cli 0.153.4, but the Chrome extension-host configuration still points to a stale plugin app-server executable reporting codex-cli 0.142.0-alpha.6 (timestamped from June).
   • The standard Native Messaging host exists and the extension is enabled, so the failure is specifically in stale/incompatible app-server registration/configuration rather than extension detection.

   The user declined an application reset because this should self-heal without deleting local app state. Please add startup/update reconciliation that validates the app-server CLI version/path before reporting the Chrome integration as installed, and provide a supported repair button for this state.
7. PracticalSwan commented on Sep 9, 2026

   

   PracticalSwan

   on Sep 9, 2026 – with ChatGPT Codex Connector

   More actions

   I can now narrow the Windows codex doctor false-negative mentioned above to a concrete path mismatch on current builds.

   Reproduced on:

   • Codex Desktop AppX 26.903.8094.0
   • codex-cli 0.153.4
   • Windows 11

   Observed at the same time:

   • the packaged Desktop process tree is live and owns its bundled codex.exe app-server child;
   • codex doctor --summary reports the desktop application is not running;
   • codex doctor --json reports desktop.app.version.details.running = false and skips the Desktop app-server handshake.

   The v0.153.4 doctor source explains the false negative. On Windows, desktop_log_root() builds the log root as %LOCALAPPDATA%\Codex\Logs, then inspect_desktop_session() only considers a Desktop process running if it finds a current session log there and validates that log filename's PID against the AppX package family:

   codex-rs/cli/src/doctor/desktop.rs (rust-v0.153.4):

   local.join("Codex/Logs")

   On the packaged Windows install, %LOCALAPPDATA%\Codex\Logs does not exist. The actual codex-desktop-...log files are under the AppX-localized path:

   %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\YYYY\MM\DD\
   

   The current live Desktop PID is present in the current-day log filenames at that virtualized location. So application_running() is never reached for that PID because discover_desktop_logs() is reading the non-virtualized host path and returns no session candidate.

   This appears to be a Doctor-only Windows AppX path-resolution bug, separate from the Chrome registration failure itself. A fix could resolve the package-localized log root on Windows (or safely check both packaged and unpackaged log roots) before doing the existing package-family PID validation.
8. PracticalSwan commented on Sep 10, 2026

   

   PracticalSwan

   on Sep 10, 2026 – with ChatGPT Codex Connector

   More actions

   Still reproducible with stable Codex CLI 0.154.0 on Windows

   After upgrading the global npm installation from 0.153.4 to stable 0.154.0, codex doctor --summary --no-color --ascii still reports the installed Codex Desktop as not running while the packaged Desktop process and its bundled app-server are both running.

   The rest of Doctor is healthy (22 ok | 1 idle | 3 notes | 1 warn | 0 fail degraded). This confirms the Windows Desktop-process detection false negative remains present in 0.154.0; it is not resolved by the stable CLI update.

   No model/agent request was issued for this check, and no credentials or private thread content are included.
9. bherreraicon commented on Sep 10, 2026

   

   bherreraicon

   on Sep 10, 2026 – with ChatGPT Codex Connector

   More actions

   Confirmed additional root cause / workaround on Windows — separate from missing runtime registration

   Following the report of a stale CLI configuration, there is another executable-path source worth checking: an inherited user-level CODEX_CLI_PATH.

   On our machine, it pointed to a nonexistent %LOCALAPPDATA%\OpenAI\CodexCLI\codex.exe, overriding a valid CLI path in chrome-native-hosts-v2.json.

   The distinguishing symptoms were: registration and runtime manifests existed, extension-host.exe listened on TCP, but app-server startup failed with os error 3. The connection closed before HTTP 101, producing Chrome WebSocket 1006.

   Read-only check:

   $cliOverride = Get-ItemPropertyValue 'HKCU:\Environment' 'CODEX_CLI_PATH' -ErrorAction SilentlyContinue
   
   if (-not [string]::IsNullOrWhiteSpace($cliOverride)) {
       $cliTarget = [Environment]::ExpandEnvironmentVariables($cliOverride)
       Test-Path -LiteralPath $cliTarget -PathType Leaf -ErrorAction Stop
   }

   After confirming the override was obsolete and the app-managed CLI was valid, we backed up and removed only that user environment value. Fully restarting Codex and Chrome restored HTTP 101, initialize, and the working side panel. Detailed checks and workaround.

   This does not explain or repair a missing chrome-native-hosts-v2.json, a broken latest junction, or the codex doctor detection issue. It is an additional check when registration is already valid but the subsequent WebSocket connection still fails.
10. PracticalSwan commented on Sep 11, 2026

    

    PracticalSwan

    on Sep 11, 2026 – with ChatGPT Codex Connector

    More actions

    Fresh structural check on Windows Codex Desktop 26.908.4834.0 after a normal Store-app launch, with no manual repair:

    • Both expected schema-v2 registration files now exist (%LOCALAPPDATA%\OpenAI\Codex\chrome-native-hosts-v2.json and %USERPROFILE%\.codex\chrome-native-hosts-v2.json). This is an improvement over the original missing-manifest reproduction.
    • However, the current Chrome plugin cache contains 26.908.40834, while the latest NTFS junction still targets removed directory 26.903.71938 (Test-Path on the junction target is false).
    • The v2 registration file has 52 entries, but its newest recorded appVersion is also 26.903.71938; it contains no entry for the current 26.908.4834.0 app generation / 26.908.40834 Chrome plugin generation.
    • Fresh Desktop startup reconciliation logs bundled_plugin_status_unknown for the Chrome plugin and then an install failure while trying to back up the existing plugin cache (Access is denied, categorized as plugin_cache_windows_file_lock).

    I did not modify the junction, manifests, plugin cache, registry, or extension state, and I did not run a functional Chrome side-panel test in this pass. So this only establishes that manifest creation has improved, while the stale-latest/update-reconciliation part of the issue still reproduces on the newer build.
11. chriswcy commented on Sep 12, 2026

    

    chriswcy

    on Sep 12, 2026

    More actions

    Feedback ID: no-active-thread-01a09658-0630-7ae2-98e1-b0a75dae54d3

    Same end state as the check in #issuecomment above (Desktop 26.908.4834.0, latest
    stranded on the removed 26.903.71938), but the junction turned out to be only half of it.
    Repairing it is not sufficient, and the reason the app-server entry never appears is
    upstream of Chrome entirely.

    1. Repointing latest at the current plugin build restores the two layers the plugin
       installer writes — %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json and
       HKCU\...\NativeMessagingHosts\com.openai.codexextension. check-native-host-manifest.js --browser chrome then reports "correct": true, "problem": null. The side panel still
       failed with "No compatible Codex app-server entry was found".

    2. The remaining blocker is the EFS copy failure tracked in Windows Store 26.707.3748.0: EFS copyfile UNKNOWN breaks bundled marketplace and Computer Use native pipe #32589. Every reconcile logged
       plugin_marketplace_folder_write_failed / bundled_plugins_marketplace_resolve_failed
       (254 times on 2026-09-12). The Chrome registration then silently no-ops, because it
       early-returns when the marketplace did not resolve:

       async function AX(e){ let t = iZ(e.pluginName);
         if (t == null || e.marketplacePath == null) return; }   // no log
       

       Nothing on the Chrome side points at the marketplace. My chrome-native-hosts-v2.json had
       not been rewritten since 2026-06-03 while the manifest and registry key looked healthy —
       which is what makes this look like an extension problem.

    3. Pointing CODEX_ELECTRON_BUNDLED_PLUGINS_RESOURCES_PATH at a stream-copied (unencrypted)
       mirror of app\resources made the reconcile succeed. The entry was written on the next
       launch with a live pid, and all layers went green.

    Two details that cost time:

    • The mirror must cover ALL of resources. Mirroring only plugins\openai-bundled fails
      later with "Missing bundled Electron Codex runtime required to sync Chrome plugin app
      server" — the app-server sync also needs codex.exe and cua_node from the resources
      root.
    • MSIX activation caches the environment block, so the app keeps reading the old value
      until Explorer is restarted.

    Net: the stale junction and the missing app-server entry are two separate faults sharing a
    trigger (an app update). Fixing only the junction leaves the side panel broken.
12. PracticalSwan commented on Sep 15, 2026

    

    PracticalSwan

    on Sep 15, 2026 – with ChatGPT Codex Connector

    More actions

    Current-state update from Microsoft Store build 26.908.9136.0 on Windows x64:

    The update/reconciliation state that was previously broken is now structurally healthy on this machine after a normal Store update/relaunch:

    • both expected chrome-native-hosts-v2.json files exist;
    • both report schemaVersion: 2 and currently contain 54 entries;
    • the Chrome plugin cache contains current build 26.908.70816;
    • the latest junction points to that existing 26.908.70816 directory;
    • both v2 registrations include 26.908.70816;
    • the normal Native Messaging manifest exists and its configured host path resolves;
    • current Desktop startup logs show no plugin_cache_windows_file_lock / relevant Access is denied reconciliation error.

    I did not manually repair the junction, manifests, registry, or plugin cache in this pass.

    This is strong evidence that the original stale-junction/missing-v2-registration update path has improved in current builds. I have not run a fresh functional ChatGPT Chrome side-panel connection test in this pass, so I am not claiming the entire user-visible issue is resolved yet.
13. Littledogewww commented on Sep 16, 2026

    

    Littledogewww

    on Sep 16, 2026

    More actions

    Additional reproduction on Codex Desktop 26.908.9136.0 (Windows x64), with a confirmed recovery of the Chrome side panel and a reproducible bundled-resource copy failure.

    Environment

    • Windows 11 25H2, build 26200.9457, x64.
    • Installed package: OpenAI.Codex_26.908.9136.0_x64__2p2nqsd0c76g0.
    • Desktop-bundled CLI: 0.154.0-alpha.6.2.
    • Chrome: 152.0.7977.83.
    • ChatGPT Chrome extension: 1.26.901.11451.
    • The app expected bundled plugins 26.908.70816, while the existing Browser/Chrome/Computer Use cache was initially 26.901.51231.

    User-visible failure and diagnostic gap

    With the desktop app running, the Chrome side panel displayed:

    Open or update the ChatGPT desktop app
    The Chrome side panel could not connect to the ChatGPT desktop app
    Technical details
    Codex Chrome native host v2 manifest is missing
    

    Both expected files were absent:

    %LOCALAPPDATA%\OpenAI\Codex\chrome-native-hosts-v2.json
    %USERPROFILE%\.codex\chrome-native-hosts-v2.json
    

    During troubleshooting, we manually restored matching plugin files and repaired the basic Native Messaging registration. At that point, the bundled check-native-host-manifest.js --browser chrome --json reported correct: true, and Codex could open a Chrome page, read it, and click a link. The side panel still failed with the missing-v2 error above. The diagnostic result therefore did not establish side-panel readiness; it checked the basic Native Messaging manifest rather than the required v2 runtime registration.

    Related provisioning failure, independently reproduced

    The desktop log repeatedly recorded these events while materializing its bundled marketplace:

    plugin_marketplace_folder_write_failed
    folderWritePhase=copy_plugins
    errorCode=UNKNOWN
    UNKNOWN: unknown error, copyfile
      '<installed-package>\app\resources\plugins\openai-bundled\plugins\sites\.app.json'
      -> '%USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled.staging-<id>\plugins\sites\.app.json'
    bundled_plugins_marketplace_resolve_failed
    

    A narrow reproduction using the desktop's bundled Node executable against that same 105-byte source file produced:

    Source attributes: Archive, Encrypted
    fs.copyFile: code=UNKNOWN, errno=-4094, syscall=copyfile
    fs.readFile + fs.writeFile: succeeds; source/destination SHA-256 match
    

    The shipped Windows encrypted-copy fallback appears to recognize errno === 6000, whereas the observed Node error here is -4094. This may explain why the readable encrypted resource never reaches that fallback. This copy signature is also reported in #32589 and #41164.

    The copy failure and missing v2 registration coexisted on this machine. A causal link through incomplete reconciliation is plausible, but we have not reproduced that complete chain on a clean installation.

    Recovery actually verified

    1. Restored the current bundled plugin files using byte reads/writes, verifying all 952 files by SHA-256, then installed the matching Browser/Chrome/Computer Use versions through the bundled CLI. Browser page control recovered, but the side panel did not.
    2. Created both missing v2 registration files according to the current installed app's schema and runtime paths, and changed the basic Native Messaging manifest to reference the current 26.908.70816 host executable. Its OpenAI Authenticode signature was valid. Allowed extension origins were unchanged; no optional process-presence heartbeat was fabricated.
    3. Retried the side panel. The user confirmed that it entered the normal chat interface. We did not submit a chat message as part of validation.

    These were manual troubleshooting changes, not an official workaround recommendation. No signed application files or Windows security settings were modified. The automatic marketplace copy error persisted after the manual file restoration, so this does not establish that future updates will work.

    Expected behavior / suggested regression coverage

    • Installation/reconciliation should provision and validate the v2 registration before considering Chrome side-panel setup complete.
    • Native-host diagnostics should distinguish basic browser-control connectivity from side-panel runtime readiness and report missing v2 files explicitly.
    • A readable encrypted WindowsApps resource that yields UNKNOWN/-4094 from native copying should be handled safely, with the last working plugin/runtime state preserved if provisioning cannot complete.

    Personal paths and instance identifiers have been redacted; no raw logs, account data, or screenshots are attached.
14. PracticalSwan commented on Sep 19, 2026

    

    PracticalSwan

    on Sep 19, 2026 – with ChatGPT Codex Connector

    Last edited by PracticalSwan

    More actions

    September 25, 2026 — Store Desktop 26.917.9434.0 structural follow-up: After a normal launch, schema-v2 registry now contains 58 historical entries and exactly one current-AppX match; the current plugin generation is 26.917.71314, all eight native-host paths exist, one native module directory exists, and all 182 generated plugin manifests parse with no oversized default prompts. The latest main-process log contains zero plugin-cache-lock, access-denied, fatal, panic or uncaught categories. No manual registry/cache repair was needed. The functional Chrome side-panel connection remains untested, so this does not resolve the reported functional issue.

    ---

    September 24, 2026 — current-build structural update: After updating to Windows Store Codex AppX 26.917.8451.0, a read-only audit found a schema-v1 legacy file and a separate schema-v2 native-host registry with 57 historical entries and exactly one current entry whose resourcesPath resolves to the new installed AppX. The current plugin generation is 26.917.62051; chrome/latest resolves to that existing cache generation. The eight required native-host paths and the current Node module directory exist, and all 182 generated plugin manifests parse without oversized default prompts. One startup plugin_cache_windows_file_lock marker was logged, but the current cache and registry are reconciled. The v1 and v2 files intentionally have different schemas and should not be expected to match byte-for-byte. I did not complete an end-to-end Chrome side-panel test, so this structural result does not close the functional issue.

    ---

    Structural follow-up on the newer Microsoft Store build 26.915.4065.0:

    • Both expected schema-v2 registration files exist and report schemaVersion: 2.
    • Each currently contains 55 entries.
    • The current Chrome bundled generation is 26.915.31945.
    • The Chrome latest junction resolves to the existing 26.915.31945 directory.
    • Both v2 registries include the current 26.915.31945 generation.
    • The normal Native Messaging manifest exists and its configured extension-host.exe resolves.
    • A second clean Desktop launch had 0 Chrome/plugin cache access-denied reconciliation records.

    No manual junction/manifest/registry/cache repair was performed in this pass. This is additional evidence that the stale-junction / missing-v2-registration state is structurally healthy on the current build. I did not run a fresh end-to-end Chrome side-panel connection test, so I am not claiming the full user-visible issue is resolved.
15. GoZippy commented on Sep 22, 2026

    

    GoZippy

    on Sep 22, 2026 – with ChatGPT Codex Connector

    Last edited by GoZippy

    More actions

    On my Windows PC, ChatGPT Desktop 26.915.4065.0 and ChatGPT Chrome extension 1.26.901.11451 were installed when I captured the original failure. The side panel reports Native host request codeRuntime/hello timed out after 5000ms.

    I found that Desktop bundles Chrome plugin generation 26.915.31945, while my local openai-bundled marketplace and enabled Codex Browser/Chrome plugin installs are 26.519.41501. The chrome/latest host path resolves to the older generation, which lacks browser-service.mjs; both expected chrome-native-hosts-v2.json registrations are absent. The ordinary Native Messaging manifest and extension origin are correct, and the registered host process did start.

    The Codex browser-client setup separately fails before tab access with e.nodeRepl?.setResponseMeta is not a function. I checked the latest 13 packaged Desktop logs and found no plugin_marketplace_folder_write_failed, bundled_plugins_marketplace_resolve_failed, or -4094 entry. EFS is enabled and the packaged WindowsApps plugin files are encrypted, while the cached files are not; I have not changed encryption or package files, and this does not show that EFS caused the mismatch.

    Defender and AppLocker logs show no direct block in the queried window. Malwarebytes is active, but I found no evidence tying it to this failure. A read-only firewall check initially found both active network profiles were Public. ChatGPT's inbound allow rules for ports 1455/1457 pointed to a K:\WindowsApps\... path, while the running Desktop processes used C:\Program Files\WindowsApps\...; the current C: path had inbound rules allowing Private and blocking Public. I found no listener in the ports/ranges named by these rules, so this path mismatch was a lead to test if the app server starts, not a proven cause of the timeout. The enabled outbound offline rule is scoped to the separate CodexSandboxOffline account, not my signed-in user. I made no firewall changes.

    Another report found the same Desktop build with current plugin and v2 registrations after a clean launch, so my machine-specific reconciliation state remains unexplained.

    I verified a prior Desktop MSIX (26.901.5280.0) from OpenAI's CDN: its Microsoft Marketplace signature is valid and its package identity is OpenAI.Codex. I also downloaded and verified the 26.915.4065.0 package for restoration. Windows initially staged the older package but deferred registration because 26.915.4065.0 was still running. AppX event XML then showed the staged 26.901 package being removed while a separate Windows Update deployment staged 26.917.6896.0. The caller was svchost.exe,wuauserv under SYSTEM and the source was x-windowsupdate://....

    Correction to my earlier retry description: the first detached retry script referenced an unset $rollback variable, so it never reached Add-AppxPackage. A corrected PowerShell 7 attempt also stopped before deployment because the Windows Appx module failed to load with 0x80131539. I then ran the corrected command under Windows PowerShell 5.1 with -ForceUpdateFromAnyVersion -ForceApplicationShutdown; that rollback succeeded. Windows reported OpenAI.Codex 26.901.5280.0 with status Ok, and all running ChatGPT.exe paths resolved to the old package.

    With 26.901.5280.0 active, the bundled plugin was 26.901.41600, but the read-only diagnostic still showed the cached plugin at 26.519.41501, no cached browser-service.mjs, both v2 registration files absent, and Overall: repair-needed. The supported browser-client bootstrap failed twice, including the required two-second retry, with the same setResponseMeta error before tab access. The downgrade therefore did not reconcile the local plugin/v2 state or change the browser-client failure. The Web Store extension remained unchanged. The app data backup contains 106 files / 395,866,821 bytes with EFS preserved and a restricted ACL.

    A non-elevated restore of the signed 26.915.4065.0 package failed with 0x80073D28 because its packaged service requires administrator privileges. The first elevated restore was launched as a Desktop child, so -ForceApplicationShutdown terminated that installer with the app. I then ran the same signed-package restore through a temporary, highest-run-level scheduled task under my interactive account. The restore log records ADD_OK; Windows reports OpenAI.Codex 26.915.4065.0 with status Ok, every running ChatGPT.exe path resolves to that package, and the temporary task was removed. The post-restore diagnostic returned to bundled plugin 26.915.31945 but still reports cached plugin 26.519.41501, missing cached browser-service.mjs, absent v2 registrations, and Overall: repair-needed. A fresh supported browser-client bootstrap after restoration again failed on both required attempts with the same setResponseMeta error before tab access.

    Could Desktop provide a supported way to refresh its bundled plugin and generate both app-server registrations, with diagnostics that distinguish native-host startup from app-server and browser-runtime readiness?

    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.
16. GoZippy commented on Sep 22, 2026

    

    GoZippy

    on Sep 22, 2026 – with ChatGPT Codex Connector

    Last edited by GoZippy

    More actions

    OpenAI's Chrome extension troubleshooting guide recommends checking the browser in Settings > Computer Use and reinstalling the extension there if restarting does not fix the connection.

    I have not completed that UI reinstall on this PC. The Chrome extension is enabled, the Native Messaging manifest and registry entry agree, and the native-host process starts, but the side panel still times out. My local Codex Browser/Chrome plugin snapshot is 26.519.41501 while the installed 26.915 Desktop bundle contains 26.915.31945; reinstalling from the configured local marketplace could put the older files back. Both app-server registration files are also absent.

    I verified a signed Desktop MSIX 26.901.5280.0 and a signed 26.915.4065.0 restore package. The first Add-AppxPackage attempt deferred the older registration while 26.915.4065.0 was running. AppX event XML then showed the staged 26.901 package being removed while a separate Windows Update deployment staged 26.917.6896.0; the caller was svchost.exe,wuauserv under SYSTEM with an x-windowsupdate://... source.

    Correction to my earlier retry description: the first detached retry script had an unset $rollback variable and never called Add-AppxPackage. A corrected PowerShell 7 attempt stopped before deployment because its Windows Appx module failed to load with 0x80131539. A corrected Windows PowerShell 5.1 command with -ForceUpdateFromAnyVersion -ForceApplicationShutdown then succeeded. Windows reported OpenAI.Codex 26.901.5280.0 with status Ok, and all running ChatGPT.exe paths resolved to that package.

    With the older Desktop active, its bundled plugin was 26.901.41600, while the Web Store extension remained 1.26.901.11451. The read-only diagnostic still reported the cached plugin at 26.519.41501, no cached browser-service.mjs, both v2 registrations absent, and Overall: repair-needed. The supported browser-client bootstrap failed twice with the same e.nodeRepl?.setResponseMeta is not a function error before tab access. The downgrade did not reconcile the cached plugin or registrations and did not change that failure.

    A non-elevated restore of the signed 26.915.4065.0 package failed with 0x80073D28 because its packaged service requires administrator privileges. The first elevated restore was launched as a Desktop child, so -ForceApplicationShutdown terminated that installer with the app. I then ran the same signed-package restore through a temporary, highest-run-level scheduled task under my interactive account. The restore log records ADD_OK; Windows reports OpenAI.Codex 26.915.4065.0 with status Ok, every running ChatGPT.exe path resolves to that package, and the temporary task was removed. The post-restore diagnostic returned to bundled plugin 26.915.31945 but still reports cached plugin 26.519.41501, missing cached browser-service.mjs, absent v2 registrations, and Overall: repair-needed. A fresh supported browser-client bootstrap after restoration again failed on both required attempts with the same setResponseMeta error before tab access.

    I also checked the Chrome extension rollback path: Google documents rollback as a publisher action in the Web Store dashboard, not a user version selector, so I left the installed ChatGPT extension unchanged. Chrome Web Store rollback.

    Does the documented Settings > Computer Use reinstall refresh the Desktop-bundled plugin and create the app-server registrations on Windows, or is there a separate supported reconciliation step?
17. sdbp-admin commented on Sep 24, 2026

    

    sdbp-admin

    on Sep 24, 2026 – with ChatGPT Codex Connector

    More actions

    I reproduced a very similar failure on Windows with Brave (same Chromium/native-host backend) and found a working workaround.

    Environment

    • Codex Desktop: 26.917.8451.0
    • bundled chrome / browser plugin: 26.917.62051
    • Brave uses the ChatGPT Chrome Web Store extension ID: hehggadaopoacecdllhhajmbjkdcmajg

    Initial state / symptoms

    • Brave extension was installed.
    • Codex Desktop → Computer use → Brave Browser reported Installed.
    • Clicking open the app from the Brave side panel correctly deep-linked into Codex Desktop, so app detection/deep linking worked.
    • The side panel nevertheless showed “Install the app to use ChatGPT in Brave Browser”.
    • Both user plugin caches were absent:
      • %USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome
      • %USERPROFILE%\.codex\plugins\cache\openai-bundled\browser
    • Native Messaging registration was absent:
      • %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json
    • Both v2 manifests were absent:
      • %LOCALAPPDATA%\OpenAI\Codex\chrome-native-hosts-v2.json
      • %USERPROFILE%\.codex\chrome-native-hosts-v2.json

    The bundled plugin sources did exist inside the current AppX install:

    ...\app\resources\plugins\openai-bundled\plugins\chrome

    ...\app\resources\plugins\openai-bundled\plugins\browser

    Both were version 26.917.62051.

    Important Windows runtime finding

    Directly executing the bundled Node runtime under C:\Program Files\WindowsApps\... failed with:

    Access is denied

    However Codex had already staged working per-user runtimes under:

    %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<id>\bin\node.exe

    and

    %LOCALAPPDATA%\OpenAI\Codex\bin\<id>\codex.exe

    Those executed normally.

    Workaround that restored the Brave side panel

    1. Re-materialize the bundled plugin cache

    With Brave closed, copy the untouched bundled chrome and browser plugin folders into:

    %USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\<plugin-version>

    %USERPROFILE%\.codex\plugins\cache\openai-bundled\browser\<plugin-version>

    I used xcopy /E /H /K /Y /G; the /G mattered because these resources are coming from WindowsApps/Application Protected storage.

    Create latest junctions for both caches pointing at the current plugin version.

    2. Run OpenAI’s own native-host installer using the working per-user runtimes

    Use:

    chrome\latest\scripts\installManifest.mjs

    but execute it with the working per-user Node runtime and pass the working per-user codex.exe, node.exe, and node_repl.exe as appServerRuntimePaths.

    That successfully generated:

    • %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json
    • chrome\latest\extension-host\windows\x64\extension-host-config.json
    • HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension

    At that point the Brave side panel advanced from “Install the app” to:

    “Codex Chrome native host v2 manifest is missing”

    So Native Messaging was now working, but the v2 app-server registration was still absent.

    3. Create the missing v2 manifests

    Create valid schema-v2 entries at:

    %LOCALAPPDATA%\OpenAI\Codex\chrome-native-hosts-v2.json

    and

    %USERPROFILE%\.codex\chrome-native-hosts-v2.json

    using the current plugin/runtime paths, current plugin version, current browser-client.mjs SHA-256, and the working per-user Codex/Node runtime paths.

    After reopening Brave, the ChatGPT side panel connected successfully.

    What this suggests

    On this machine there were at least three provisioning failures in sequence:

    1. the bundled browser plugins were never materialized into the user cache;
    2. the packaged WindowsApps Node runtime could not execute (Access is denied), while the staged per-user runtime worked;
    3. the chrome-native-hosts-v2.json registrations were never generated.

    Reinstalling the browser extension did not help because it only affected the browser-side extension; the broken state was in the desktop/native-host provisioning path.

    This workaround is manual/unsupported, but it did restore the integration. It would be useful if Desktop reconciliation could:

    • materialize/repair the current plugin caches and latest junctions;
    • use executable per-user runtimes when WindowsApps resources are protected;
    • regenerate both v2 manifests before showing browser integration as Installed.

    I can provide the exact PowerShell repair logic if useful, but the key point is that the missing v2 manifests were only the final visible symptom; the earlier cache/runtime provisioning failures had to be fixed first.
18. l970421y-dotcom commented on Sep 27, 2026

    

    l970421y-dotcom

    on Sep 27, 2026 – with ChatGPT Codex Connector

    More actions

    Assistant-submitted current-build reproduction at the GitHub account owner's explicit request.

    I can independently reproduce this on Windows with a newer build:

    • Windows 25H2, build 26200.9457
    • Codex Desktop AppX: 26.924.2738.0
    • Bundled CLI: codex-cli 0.158.0-alpha.2.1
    • Bundled Chrome plugin: 26.924.22138
    • Google Chrome: 154.0.8037.57
    • ChatGPT Chrome extension: 1.26.901.11451_0
    • Selected Chrome profile: Profile 2

    Observed state:

    • Settings > Computer use reports Google Chrome as installed/enabled, shows Manage, and the toggle is on.
    • The official extension diagnostic reports the extension installed, registered, and enabled in Profile 2.
    • The Native Messaging manifest and HKCU registration exist and agree.
    • However, the manifest points to:
      %USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host.exe
    • chrome\latest does not exist. Only the current version directory chrome\26.924.22138 exists, so the manifest target is missing.
    • Both v2 registration files still contain stale 26.825.32147 entries:
      • %LOCALAPPDATA%\OpenAI\Codex\chrome-native-hosts-v2.json
      • %USERPROFILE%\.codex\chrome-native-hosts-v2.json
    • Those stale entries reference a removed OpenAI.Codex_26.825.4187.0 AppX resources path and, in other entries, deleted temporary recovery paths.
    • The supported browser runtime returns Browser is not available: chrome.

    Troubleshooting performed:

    1. Fully restarted Codex Desktop and Chrome.
    2. Opened a new Chrome window in the selected Profile 2 and retried.
    3. Removed and re-added the official Browser, Chrome, and Computer Use plugins with the current bundled CLI. The payload updated successfully, but chrome\latest and the v2 entries were not rebuilt.
    4. Used Settings > Computer use > Google Chrome > Reinstall extension. This opened the Chrome Web Store; the extension was already installed. The extension's Open installer flow opened Microsoft Store, which reported the latest desktop app installed, then returned to Codex Desktop. The bridge state remained unchanged.
    5. Confirmed the relevant writable plugin, v2 manifest, per-user Node runtime, and per-user Codex executable files are not EFS-encrypted, so the EFS-specific workaround reported above does not match this machine.
    6. Did not manually fabricate the v2 JSON files and did not run installManifest.mjs.

    This confirms that the update/reinstall reconciliation failure still reproduces on Desktop 26.924.2738.0. The UI reports the integration as installed even though the Native Messaging manifest target is missing and the app-server registrations are stale.

    Please make the Desktop reconciliation path atomic: rebuild chrome\latest, regenerate both current v2 entries, validate that all referenced paths exist, and only then report the Chrome integration as installed. A supported Repair action for this state would also avoid requiring users to edit junctions, manifests, or registry data manually.
19. Littledogewww commented on Sep 30, 2026

    

    Littledogewww

    on Sep 30, 2026

    More actions

    Recurrence after another user-performed upgrade: Desktop 26.928.2636.0 now fails on nodePath

    Follow-up to my earlier report in this thread, submitted at the affected user's explicit request. The user confirms that they performed another version upgrade immediately before this recurrence.

    The Chrome side panel currently displays:

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

    Observed on October 1, 2026 (Asia/Singapore):

    • Installed/running Codex Desktop package: 26.928.2636.0.
    • Currently running desktop CLI: codex-cli 0.159.2.
    • Current staged Node: v24.21.0, executable and working.
    • Current bundled Chrome plugin: 26.928.21956.
    • Google Chrome: 154.0.8037.92.
    • The running Native Messaging host still comes from cached Chrome plugin 26.924.22138.

    Both schema-v2 registries exist:

    %LOCALAPPDATA%\OpenAI\Codex\chrome-native-hosts-v2.json
    %USERPROFILE%\.codex\chrome-native-hosts-v2.json
    

    Each still contains the single 26.924.22138 entry last refreshed on September 30 local time. The fields are present, but several referenced targets no longer exist:

    Registered target	Current read-only result
    paths.nodePath under the previous hashed per-user runtime directory	Missing
    paths.nodeReplPath in that same previous runtime	Missing
    Previous nodeModuleDirs directory	Missing
    paths.resourcesPath under OpenAI.Codex_26.924.2738.0	Missing
    Previously registered paths.codexCliPath	Still exists, although the desktop now runs a different CLI directory
    Registered host executable in Chrome plugin 26.924.22138	Still exists and is running

    The new staged Node and Node REPL paths exist, and the desktop's current node_repl configuration points to an existing executable. Thus the visible “missing required path nodePath” error corresponds to an existing manifest property whose old filesystem target was removed, rather than an absent Node installation.

    Current Desktop logs also still contain:

    2026-09-30T16:35:37.783Z
    plugin_marketplace_folder_write_failed
    errorCode=UNKNOWN
    
    2026-09-30T16:35:37.911Z
    bundled_plugins_marketplace_resolve_failed
    errorCode=UNKNOWN
    

    This matches the earlier provisioning failure category. I have not established a complete causal chain from copying to registry migration on a clean installation.

    Troubleshooting history matters: this installation has received the manual, backed-up plugin-cache and v2-registration repairs described earlier. On September 30, the paths were refreshed for Desktop 26.924.2738.0 and Chrome plugin 26.924.22138, and their existence was verified. I did not receive an end-to-end side-panel confirmation for that specific repair. The user then performed another desktop upgrade, and the current stale paths/new nodePath error were observed. This is evidence that the manual repair does not survive this update; it is not a clean-install reproducer. No further configuration repair was performed during this feedback collection.

    Please investigate upgrade reconciliation and runtime cleanup together: a current compatible v2 entry should be generated and validated as part of upgrading, and registrations should not be left pointing at removed runtimes. A supported repair action should refresh all required paths and detect existing-but-invalid fields. This recurrence is also closely related to #40357.

    Personal directory names, process/entry identifiers, and runtime hashes are omitted. No raw screenshot, full logs, credentials, or account data are attached.
20. Littledogewww commented on Oct 1, 2026

    

    Littledogewww

    on Oct 1, 2026

    More actions

    Verified related provisioning failure: local executor startup blocked by copying bundled codex-app-tools on Windows

    Follow-up to the upgrade recurrence described in my previous comment. This affects the local executor used for Dot/local-computer access, in addition to the earlier Chrome registration symptoms. This is the same affected installation, which has received the previously disclosed manual repairs; it is not a clean-install reproducer.

    Environment on October 1, 2026:

    • Windows desktop package: 26.928.2636.0.
    • App update API: application version 26.928.21956, build 12404, channel prod, status up_to_date.
    • Bundled codex-app-tools plugin: 0.1.5.
    • Bundled Node: v24.21.0.

    The desktop Dot profile showed Your computer — Connection status unavailable. The Windows Computer Use helper was able to list desktop windows, so a working local UI helper did not imply that the local executor had registered successfully.

    Desktop logs showed a persistent restart loop:

    [tpp-local-executor] Local Work executor startup failed
    errorCode=UNKNOWN
    UNKNOWN: unknown error, copyfile
      <MSIX app resources>/plugins/openai-bundled/plugins/codex-app-tools/.codex-plugin/plugin.json
      -> <app user data>/executor-plugins/codex-app-tools/.codex-plugin/plugin.json
    

    The old process eventually reached attempt 5818 with the same copy failure before the user exited it. This occurred during capability-root preparation, before executor registration could complete.

    I reproduced the file operation separately using the app's staged Node:

    1. fs.copyFile from the packaged plugin manifest to a writable scratch directory failed with the same UNKNOWN error.
    2. Reading the same source normally, writing its bytes to a writable directory, and then using fs.copyFile on that copy succeeded.
    3. A recursive fs.cp of the complete codex-app-tools plugin from the byte-written copy succeeded.

    A temporary, per-launch workaround was tested. A copy of the current bundled plugin tree was created using normal byte reads/writes, with all 832 files verified by SHA-256 against the package contents. The current client's existing CODEX_ELECTRON_BUNDLED_PLUGINS_RESOURCES_PATH setting was pointed to that resource tree for the new process only. No persistent environment setting, patched app binary, security-setting change, or access-grant change was made.

    After the user exited and restarted the app with this setting:

    2026-10-01T04:27:34.355Z
    [tpp-local-executor] Local Work executor connected to rendezvous attempt=1
    
    2026-10-01T04:27:46.351Z
    [tpp-local-executor] Local Work executor connected to rendezvous attempt=3
    

    The new process log contained zero Local Work executor startup failed events at verification, and the executor plugin manifest was present. Attempt 2 encountered an unexpected EOF during handshake during an environment registry request; automatic retry on attempt 3 connected successfully. That transient transport failure should not be conflated with the original repeatable local copy failure.

    This verifies recovery of plugin provisioning and local-executor connectivity. It does not establish that every Dot local task works, that future upgrades are repaired, or that this workaround is generally supported. The official local-access deployment guide also specifies desktop 26.929 or later; this affected installation is older, and its configured updater reported no eligible update. Account/workspace rollout was not independently established.

    Please investigate the Windows bundled-file copy/materialization failure for both the plugin marketplace and the local executor. Avoiding an indefinite restart loop, retaining a clear actionable error, and providing a supported repair or update reconciliation path would help.

    Paths are generalized. No original screenshots, full logs, credentials, local source/executables, or personal/account identifiers are included.
21. Littledogewww commented on Oct 2, 2026

    

    Littledogewww

    on Oct 2, 2026

    More actions

    Post-restart verification: local Computer Use works, but a fresh Dot-started task still lacks node_repl

    Follow-up to the executor recovery report. After another Windows desktop upgrade and repair, the local executor now connects, but this does not restore Computer Use in a new Dot-started local task. The same installation has the previously disclosed manual resource-copy workaround; this is not a clean-install reproducer.

    Environment verified on October 2, 2026:

    • Desktop app 26.928.40906, build 12694, channel prod.
    • MSIX package 26.928.4866.0; bundled CLI 0.159.2.
    • Computer Use skill/plugin 26.928.40906.
    • App started through its registered Windows application entry; package identity was verified successfully.

    After the user fully exited and restarted the app with the current-version resource mirror:

    1. Desktop logs selected existing current-version Node, CLI, and node_repl paths. The local executor connected twice. At the audit snapshot, the new process had zero executor startup failures, zero UNKNOWN copyfile events, and zero node-repl-missing events. Local MCP logs showed node_repl ready.
    2. In an ordinary local Codex conversation on this same PC, the official node_repl imported @oai/sky; sky.list_windows() returned 6 windows. Only enumeration was tested.
    3. A fresh Dot-started computer task, created after this restart, read the current Computer Use skill but reported 234 callable tools with no node_repl. It could not initialize @oai/sky or enumerate Windows windows. No durable-host node_repl startup event appeared in the desktop log snapshot.

    The fresh task also had startup failures for cua_repl, codex_app, and notion; later durable tasks did show cua_repl ready. These are separate observations, not proof that those failures cause the missing node_repl tool.

    Read-only inspection of the installed desktop code shows a relevant distinction:

    • Per-conversation MCP configuration generation calls buildMcpCodexConfig only when the host is local; other hosts receive null through that path.
    • Local-executor registration and environment-ready messages advertise selected installed plugin/skill roots. Those payloads do not themselves carry the global standalone mcp_servers.node_repl definition.
    • The current Windows Computer Use plugin has no .mcp.json. The unified Computer Use plugin provides cua_repl, whose generated Windows surface list is browser; the desktop code adds its computer surface only on macOS. Windows desktop Computer Use still requires the standalone node_repl entry.

    This suggests a tool provisioning/forwarding or version-support gap. It does not establish which Rust executor or backend component omits the tool; those implementations were not verified. The earlier path repair was necessary to recover local configuration and executor connectivity, but was insufficient to recover Dot Computer Use.

    Related reports: #49458 and #49488. The enterprise local-access guide specifies desktop 26.929 or later, while this installation remains 26.928.40906; that compatibility requirement may matter, but is not a confirmed explanation for this installation's tool discrepancy.

    Could maintainers confirm the supported Windows version and the intended mechanism for making standalone node_repl available to Dot-started local tasks? A supported remediation would be preferable to further local manifest or application patches.

    No screenshots, credentials, device/account identifiers, private paths, raw logs, or application binaries are attached. No app binary or security-setting patch was made for this verification.
22. Littledogewww commented on Oct 2, 2026

    

    Littledogewww

    on Oct 2, 2026

    Last edited by Littledogewww

    More actions

    New-version retest: executor recovered, but a brand-new Windows Dot task still lacks node_repl

    Follow-up to the previous tool-gap verification. This installation has the previously disclosed manual resource-copy workaround and standalone local node_repl MCP configuration; this is not a clean-install reproduction.

    Verified environment on October 2, 2026 (UTC+08:00):

    • MSIX package 26.930.2377.0.
    • Desktop app/Computer Use component 26.930.21537, build 12776, prod.
    • Bundled CLI actually reports 0.159.0-alpha.12.1.

    After this upgrade, UNKNOWN copyfile from the packaged app-tools resources again prevented the local executor from starting. A version-specific copy of the current signed resources, with hashes verified against the installed package, was prepared. This version independently resolves bundled plugin resources and runtime resources, so the registered Windows application launch supplied both resource-path settings temporarily. The original user environment was restored afterward; package identity was preserved. No application binary or security setting was patched.

    After the user restarted at approximately 06:47 UTC:

    1. The new process selected valid current resources and the executor connected. At the 07:13 UTC snapshot, executor startup failures, UNKNOWN copyfile events and node-repl-missing events were all zero. These counts do not certify Dot tool availability.
    2. An ordinary local conversation on the same installation invoked the official node_repl, imported @oai/sky, and sky.list_windows() returned 6 windows. No clicking, typing or screenshots were tested.
    3. An existing Dot test task still reported a missing official JavaScript entry point, so we requested a brand-new Dot-created local Windows task after the restart. That new task was created around 07:04 UTC and completed its initial read-only check around 07:06 UTC. Successful Windows PowerShell execution and the new task's creation time were independently confirmed through the supported thread reader.
    4. The brand-new task reports that node_repl js is absent and no tool_search entry point is available. Its delegated tool-inventory check reports 324 tools with no node_repl match. This is task-reported inspection, not an independently captured backend tool manifest. The task could not initialize @oai/sky or attempt window enumeration; its window count is unknown, not zero.

    Thus the current reproduction is not limited to resuming a pre-upgrade task. Executor connectivity and ordinary local Computer Use have recovered, while Dot Computer Use has not.

    Read-only checks found computer_use, browser_use and plugins already enabled in the local CLI, and an existing standalone mcp_servers.node_repl entry. No documented dedicated exec-server forwarding option was found. The desktop source still shows different capability-assembly paths for local conversations and executor/Dot tasks. This suggests a provisioning/forwarding gap, but does not establish which client, Rust executor or backend layer is responsible; opening a development flag is not a verified remediation.

    Separately, an earlier task-creation attempt reported failure. The local log records a brief pong_timeout, WebSocket close 1006, then automatic executor reconnection about 11 seconds later. We cannot establish that interruption as the cause of the creation failure or the missing tools. The subsequent brand-new task above did complete its check.

    Related same-component reports: #49458 and #49488. Could maintainers confirm the supported mechanism for exposing the official Windows Computer Use entry point to a fresh Dot task on this version, and which sanitized diagnostic would locate the missing tool-provisioning step?

    No credentials, account/device/task identifiers, private paths, window titles, screenshots or raw logs are attached.

    Further read-only localization: standalone stdio is excluded from executor-config discovery

    The public tag rust-v0.159.0-alpha.12.1 matches the installed CLI version string and resolves to commit 180d8caaac22c656bfc6329f2f573ee1430cbe20. This is version association, not a reproducible-build attestation for the Windows binary or cloud orchestrator.

    • exec-server/src/environment_config.rs:113-118 retains only local MCP definitions containing url. The current standalone node_repl has command and no url; a read-only projection of the actual local TOML through that predicate removes it.
    • core/src/session/mcp_runtime.rs:226-233 independently accepts only StreamableHttp on this route. Removing just the first filter would not supply a stdio launcher.
    • The separate selected-plugin route can bind a command MCP to the executor environment, as shown by codex-mcp/src/plugin_config.rs:126-167. The current official Windows Computer Use plugin has neither inline mcpServers nor .mcp.json; its node_repl hook references do not declare a server.

    Actual desktop telemetry records local node_repl ready states and no durable node_repl startup event, consistent with a missing registration. That absence is not a complete live cloud catalog capture. Same-window cua_repl startup failures are separate evidence and do not establish the cause of node_repl omission.

    A user-owned ordinary MCP companion-plugin draft, pointing to the existing official runtime, was accepted by the installed CLI's local marketplace-add and plugin-add commands in an isolated temporary Codex home. It was not activated in the user's profile or tested in Dot, and is not a verified remediation. Dynamic native-pipe/service environment values require correct executor binding; a static clone must not be reused blindly after restart or upgrade.

    The first concrete boundary is now the URL-only executor-config discovery plus the absent selected-plugin declaration. Could the supported Windows Dot provisioning path register the official stdio entry point through the environment-owned plugin route, or does another cloud injection path intentionally supply it?
23. l970421y-dotcom commented on Oct 2, 2026

    

    l970421y-dotcom

    on Oct 2, 2026 – with ChatGPT Codex Connector

    More actions

    Thanks @Littledogewww and @sdbp-admin for sharing the workaround. It worked for me on Windows with Codex Desktop 26.930.2377.0 (bundled plugin 26.930.21537). Restoring the current official plugin files, repairing the Chrome latest junction, and rebuilding both v2 registrations with the current runtime paths restored the integration. Browser control was tested successfully, and I’ve confirmed the Chrome side panel is working again. No signed application files or Windows security settings were changed. This is a successful manual workaround, not confirmation of an official fix. Thanks again!
24. clarkey31 commented on Oct 10, 2026

    

    clarkey31

    on Oct 10, 2026

    More actions

    Confirmed workaround on Windows: Desktop 26.1007.2314.0, Chrome plugin 26.1007.21434

    Symptoms: the side panel first showed "Install the app to use ChatGPT in Chrome". After fixing the manifest, it showed No compatible Codex app-server entry was found. Restarting, "Reinstall extension" and the EFS checks changed nothing. No CODEX_CLI_PATH override and no encrypted files.

    Root cause on my machine:

    • chrome\latest junction was still pointing at a removed version.
    • %LOCALAPPDATA%\OpenAI\Codex\chrome-native-hosts-v2.json had not been updated since the previous version (26.1002). The new version never wrote its entry.
    • The newest existing entry pointed to a cua_node runtime folder that had been renamed to .bak.

    Fix (back up both files first):

    1. In %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json, change path to use the real version folder instead of latest, e.g. ...\chrome\26.1007.21434\extension-host\windows\x64\extension-host.exe.
    2. In chrome-native-hosts-v2.json, copy the newest entry and insert the copy at the top of entries, then edit the copy:
       • appVersion, cliVersion, nativeHostVersion → the plugin version (from chrome\<version>\.codex-plugin\plugin.json)
       • new random entryId
       • browserClientPath, browserServicePath, extensionHostPath → ...\chrome\<version>\... (not latest)
       • nodePath, nodeModuleDirs, nodeReplPath → the cua_node\<id> folder that actually exists in %LOCALAPPDATA%\OpenAI\Codex\runtimes\
       • resourcesPath → current package from (Get-AppxPackage *OpenAI.Codex*).InstallLocation + \app\resources
       • updatedAt / presence → current timestamp
    3. Keep the app open and click "Try again" in the side panel. It connected immediately.

    This will likely break again on the next update until the app reliably rewrites the v2 entry and repoints latest. A "repair registration" button would solve this for everyone.