[Windows] Browser plugins fail trusted RPC dependency validation #39486

Activity

1. PVSB78

   added

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

   on Aug 19, 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

   safety-checkIssues related to safety and abuse checksIssues related to safety and abuse checks

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

   

   github-actionsBot

   on Aug 19, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Windows: shared Browser runtime rejects bundled browser-service during trusted RPC validation #39407
   • [Windows] Browser/Chrome plugin fails trusted RPC dependency path validation #39399
   • Windows regression that completely disables both the built-in Browser and Chrome control. #39414
   • OpenAI Support Diagnostic: Browser and Chrome Runtime Bootstrap Failure #39252
   • Browser plugin fails trusted-path check; Chrome native host reported out of date #39427

   Powered by Codex Action
4. imatchgames commented on Aug 19, 2026

   

   imatchgames

   on Aug 19, 2026 – with ChatGPT Codex Connector

   More actions

   Independent reproduction on Windows.

   I can reproduce the same trusted RPC dependency failure with the bundled Browser and Chrome plugins at version 26.814.41407:

   Trusted RPC dependency must resolve within a configured trusted code path:
   .../browser-service.mjs
   

   Impact:

   • In-app browser control cannot initialize.
   • Chrome control cannot initialize, even though the Chrome extension is installed and enabled.
   • Reinstalling the extension, enabling browser control, fully restarting Codex/Chrome, and terminating remaining processes did not resolve it.
   • The failure prevents a real authenticated web-administration workflow; the browser window opens and remains usable manually, but the agent cannot interact with it.

   I also tested the Computer Use path. It can detect the open Chrome window, but it stops before interaction because it cannot determine the current browser URL with enough confidence to enforce policy. This leaves both browser-control paths unusable.

   Expected: the official bundled browser service should initialize successfully and control authenticated browser tabs after the user has enabled the relevant permissions.

   👍React with 👍2Reacted by Raja Khoury and chrisma2021
5. imatchgames commented on Aug 19, 2026

   

   imatchgames

   on Aug 19, 2026 – with ChatGPT Codex Connector

   More actions

   Update: tested the remaining enabled browser paths as well.

   • Microsoft Edge: initialization fails with the same Trusted RPC dependency must resolve within a configured trusted code path ... browser-service.mjs error.
   • Brave: the Windows Computer Use integration can detect the Brave window, but stops before it can read or interact with the page because it cannot determine the current browser URL with enough confidence to enforce policy.

   Confirmed affected paths on this Windows system:

   1. Codex in-app Browser
   2. Google Chrome extension control
   3. Microsoft Edge extension control
   4. Brave through Computer Use

   All enabled browser-control paths are therefore unavailable for authenticated web-administration tasks.

   👍React with 👍1Reacted by Raja Khoury
6. akbluemoose commented on Aug 20, 2026

   

   akbluemoose

   on Aug 20, 2026

   More actions

   I can reproduce this on Windows with bundled Browser/Chrome plugin 26.814.41407.

   I verified the Chrome/native-host setup is healthy:

   • ChatGPT Chrome extension installed and enabled
   • Extension ID matches the native-host manifest
   • com.openai.codexextension registry entry exists
   • Native-host manifest exists and parses correctly
   • allowed_origins is correct
   • extension-host.exe exists and has a valid Authenticode signature
   • OpenAI’s bundled check-native-host-manifest.js reports Correct: yes
   • OpenAI’s bundled check-extension-installed.js reports the extension installed and enabled
   • Chrome successfully launches the native host:
     chrome.exe -> cmd.exe -> extension-host.exe

   Despite that, browser initialization fails with:

   Trusted RPC dependency must resolve within a configured trusted code path

   After the failure, Codex sometimes reports that the native-host registry/manifest or Chrome profile are missing, but direct inspection and OpenAI’s own diagnostics confirm they are present.

   I also deleted and regenerated both bundled browser caches. They came back as 26.814.41407, and the issue persisted.

   I tested with another browser-control extension disabled as well, with no change.

   This appears to be failing after native messaging launches successfully, during Codex trusted-code-path/RPC validation rather than during Chrome/native-host installation.
7. imatchgames commented on Aug 20, 2026

   

   imatchgames

   on Aug 20, 2026 – with ChatGPT Codex Connector

   More actions

   Thank you — this matches our Windows reproduction closely and supports that the issue is in Codex's trusted-code-path/RPC validation, not browser setup.

   In our case, the failure now also shows a version mismatch: Codex attempts to import browser-service.mjs from bundled Browser plugin 26.814.41957, but that path is absent locally. The control failure affects the in-app browser, Chrome, Edge, and Brave. Reinstalling extensions, restarting the app/browsers, and terminating residual processes did not resolve it.

   This blocks authenticated browser tasks despite the Computer Use permissions and browser extensions being enabled.
8. imatchgames commented on Aug 20, 2026

   

   imatchgames

   on Aug 20, 2026 – with ChatGPT Codex Connector

   More actions

   Full Windows reproduction report

   Impact: browser control is unavailable for authenticated administrative work (for example, Name.com), even though Computer Use and browser permissions are enabled.

   Browsers affected

   • In-app Browser
   • Google Chrome
   • Microsoft Edge
   • Brave

   Configuration checked

   • “Any app” control enabled in Settings → Computer use.
   • ChatGPT browser extensions installed and enabled for Chrome, Edge, and Brave.
   • The affected browser sessions were open and signed in.

   Actions already tried

   1. Reinstalled the browser extensions.
   2. Restarted Codex/Desktop and all browsers.
   3. Terminated residual application/browser processes using Windows Task Manager.
   4. Retried after reinstalling/enabling the controls.
   5. Tested all four browser paths, not just Chrome.

   Observed failures

   • In-app Browser, Chrome, and Edge fail before a tab can be controlled due to trusted RPC / trusted code path initialization errors.
   • Current error additionally shows a bundled-component version mismatch: the runtime attempts to load browser-service.mjs from Browser plugin 26.814.41957, but the module is absent locally.
   • Brave is detected, but Computer Use stops before page interaction because it cannot determine the current browser URL with enough confidence to enforce policy.

   The failures persist after the above recovery steps. This does not appear to be a missing extension, browser login, or user configuration issue; it appears to be an internal desktop/browser-plugin infrastructure issue. Please investigate the trusted worker component/version packaging and the trusted RPC validation path.
9. imatchgames commented on Aug 20, 2026

   

   imatchgames

   on Aug 20, 2026 via email

   More actions

   Thank you for the detailed confirmation. Our Windows setup reproduces the same failure and we are adding the complete operational impact and checks performed. Impact: browser control is unavailable for authenticated administrative work, even with the relevant permissions enabled. Affected browser paths: - In-app Browser - Google Chrome - Microsoft Edge - Brave Configuration verified: - “Any app” control is enabled in Settings → Computer use. - The ChatGPT browser extensions are installed and enabled for Chrome, Edge, and Brave. - The required browser sessions were open and signed in. Recovery actions already tried: 1. Reinstalled the browser extensions. 2. Restarted the Codex desktop app and all browsers. 3. Closed residual Codex/browser processes via Windows Task Manager. 4. Re-enabled the controls and retried. 5. Tested all four browser paths, not only Chrome. Observed failures: - In-app Browser, Chrome, and Edge fail before a tab can be controlled with trusted RPC / trusted-code-path initialization errors. - The current error also shows a bundled-component version mismatch: the runtime attempts to load browser-service.mjs from Browser plugin 26.814.41957, but the module is absent locally. - Brave is detected, but Computer Use stops before any page interaction because it cannot determine the current browser URL with enough confidence to enforce policy. The issue persists after the above recovery steps. This appears to be an internal desktop/browser-plugin infrastructure issue rather than an extension installation, browser login, or user configuration problem.
10. evdmaaten commented on Aug 25, 2026

    

    evdmaaten

    on Aug 25, 2026 – with ChatGPT Codex Connector

    More actions

    Additional Windows reproduction on 2026-08-25.

    Environment:

    • Platform: Windows x64
    • Bundled Browser plugin: 26.818.61809
    • Rejected dependency: %USERPROFILE%\.codex\plugins\cache\openai-bundled\browser\26.818.61809\scripts\browser-service.mjs

    Observed error:

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

    Reproduction:

    1. Start a projectless Codex Desktop task on Windows.
    2. Attempt an in-app browser task targeting ChatGPT.
    3. The browser runtime fails during initialization, before navigation, tab discovery, or authentication.
    4. Fully restart Codex Desktop and retry.
    5. The identical error persists.

    Verification:

    • The versioned Browser bundle directory exists.
    • Both browser-client.mjs and browser-service.mjs are present in the official bundled plugin path.
    • The failure therefore remains reproducible with the newer 26.818.61809 Browser bundle, not only the earlier 26.814.41407 bundle described in the original report.

    Impact:

    • All in-app browser interaction is blocked.
    • This prevented creating and organizing ChatGPT Projects through the signed-in UI.

    Privacy:

    • Username, task ID, and local user path are omitted.

    This comment was submitted by Codex at the account owner's explicit request after reproducing the failure multiple times.
11. gtocue commented on Aug 30, 2026

    

    gtocue

    on Aug 30, 2026 – with ChatGPT Codex Connector

    More actions

    Independent reproduction with authority-level diagnostics on Windows 11 build 26200.9168 x64.

    I am seeing the same failure stage: Trusted-RPC dependency validation fails before browser discovery/attachment.

    Additional diagnostics from this reproduction:

    • OpenAI browser-control plugin authority is present and enabled.
    • Attachment transport registration is present.
    • Browser-control registration and native-host ownership resolve to an OpenAI shared runtime.
    • The native-host target is present, declared by that owner authority, and content-matches that authority.
    • The Trusted-RPC dependency authority is present, but it is not declared by the owning runtime and its content does not match the runtime authority.
    • Trusted-RPC dependency validation fails and attachment transport remains unavailable.
    • The plugin ↔ Trusted-RPC generation relationship was authority-aligned in the bounded check; raw local OpenAI/runtime/plugin version identities were not authoritatively available, so I am not claiming an exact version match to the original report.
    • No exact signed OpenAI repair surface scoped only to the Trusted-RPC/shared-browser-runtime dependency was available locally.

    This narrows the observed failure boundary to the OpenAI shared-runtime → Trusted-RPC authority edge after the native-host authority checks, rather than proving a browser/site-specific failure. I am not asserting an upstream root cause beyond that observed boundary.

    Environment:

    • Windows 11 Home build 26200.9168
    • x64

    Repair status for this reproduction:

    • broad Windows/app repair not attempted
    • product update not attempted
    • reinstall not attempted
    • manual registry/trust/cache repair not attempted

    Browser-control attachment remains blocked before any target website is reached.
12. imatchgames commented on Aug 31, 2026

    

    imatchgames

    on Aug 31, 2026 via email

    More actions

    Hi everyone, Thank you for the detailed diagnostic breakdown. I wanted to update you that the issue is now resolved on my end, and I currently have full control over the browsers again. The solution was completely uninstalling Codex from the system and performing a fresh installation from scratch. Since the reproduction report noted that a reinstall wasn't attempted yet, doing a clean install should fix the Trusted-RPC dependency validation failure and restore the attachment transport. Best regards, Maximiliano. El dom, 30 ago 2026 a la(s) 5:29 a.m., gtocue ***@***.***) escribió:

    …

    *gtocue* left a comment (openai/codex#39486) <#39486 (comment)> Independent reproduction with authority-level diagnostics on Windows 11 build 26200.9168 x64. I am seeing the same failure stage: Trusted-RPC dependency validation fails before browser discovery/attachment. Additional diagnostics from this reproduction: - OpenAI browser-control plugin authority is present and enabled. - Attachment transport registration is present. - Browser-control registration and native-host ownership resolve to an OpenAI shared runtime. - The native-host target is present, declared by that owner authority, and content-matches that authority. - The Trusted-RPC dependency authority is present, but it is not declared by the owning runtime and its content does not match the runtime authority. - Trusted-RPC dependency validation fails and attachment transport remains unavailable. - The plugin ↔ Trusted-RPC generation relationship was authority-aligned in the bounded check; raw local OpenAI/runtime/plugin version identities were not authoritatively available, so I am not claiming an exact version match to the original report. - No exact signed OpenAI repair surface scoped only to the Trusted-RPC/shared-browser-runtime dependency was available locally. This narrows the observed failure boundary to the OpenAI shared-runtime → Trusted-RPC authority edge after the native-host authority checks, rather than proving a browser/site-specific failure. I am not asserting an upstream root cause beyond that observed boundary. Environment: - Windows 11 Home build 26200.9168 - x64 Repair status for this reproduction: - broad Windows/app repair not attempted - product update not attempted - reinstall not attempted - manual registry/trust/cache repair not attempted Browser-control attachment remains blocked before any target website is reached. — Reply to this email directly, view it on GitHub <#39486?email_source=notifications&email_token=CJ6RLJUODKJRPM5SMJ24YGL5MPQXHA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNBWG43DIMBYHEZ2M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5467640893>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CJ6RLJTG65JVQWTERKKPEP35MPQXHAVCNFSNUABFKJSXA33TNF2G64TZHM4TMNJUGE2TMNBZHNEXG43VMU5TKMJZGMYDEMJZGA4KC5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CJ6RLJSRAD5BUAHE4PHNMJL5MPQXHA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNBWG43DIMBYHEZ2M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/CJ6RLJT6ELPSMHS5UAISN2L5MPQXHA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNBWG43DIMBYHEZ2M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you commented.Message ID: ***@***.***>
13. coldeyesier commented on Sep 8, 2026

    

    coldeyesier

    on Sep 8, 2026 – with ChatGPT Codex Connector

    More actions

    Additional reproduction on Windows x64, verified again after a full Windows restart on 2026-09-08.

    Environment:

    • Codex desktop package version: 26.901.6511.0
    • Bundled Browser plugin: 26.901.51231
    • Windows-native agent
    • User CODEX_HOME: E:\codex
    • %USERPROFILE%.codex is a directory junction to E:\codex.
    • Projectless task directory is separate from CODEX_HOME.

    Verified after reboot:

    • The Browser skill is available in the task.
    • The shell process reports CODEX_HOME=E:\codex.
    • The node_repl tool configuration in config.toml sets CODEX_HOME to E:\codex.
    • Its NODE_REPL_TRUSTED_CODE_PATHS includes E:\codex and the bundled Node modules directory.
    • The bundled marketplace source is E:/codex/.tmp/bundled-marketplaces/openai-bundled.

    A single initialization attempt through the provided Browser skill still fails:

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

    The attempted setup imports browser-client.mjs from the same versioned E: directory and calls setupBrowserRuntime(). It fails before in-app browser selection/documentation, tab discovery, or navigation. No target website, authentication, or form interaction is reached.

    Troubleshooting context:

    • Previously corrected a Windows bundled-marketplace source that used a WSL-style /mnt/e/... path.
    • Setting CODEX_HOME to the E: directory and restarting restored Browser skill availability, but did not resolve Trusted RPC initialization.
    • The same initialization error persists after restarting the desktop app and after a full Windows reboot.
    • No trust-validation bypass or alternate browser-control mechanism was used for these reproduction attempts.
    • Chrome/Edge were not tested in this reproduction; the confirmed result here is the in-app Browser bootstrap failure.

    The observed configuration contains the rejected file's parent root, but this does not prove the trusted-service subprocess receives or interprets that configuration correctly. Junction handling, path canonicalization, and environment propagation remain hypotheses, not established causes.

    Please investigate and provide a supported repair/update procedure that preserves existing CODEX_HOME data. No full configuration, session transcript, credentials, private website URL, or browser data is attached.

    Submitted with the account owner's authorization.