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

   computer-use

   browser

   automations

   on Aug 24, 2026
2. github-actions commented on Aug 24, 2026

   

   github-actionsBot

   on Aug 24, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • [Windows 26.818] Built-in Browser fails trusted RPC dependency validation #40405
   • [Windows 26.814] Browser and Chrome control stopped after morning component update #39305
   • Windows regression that completely disables both the built-in Browser and Chrome control. #39414
   • Windows: shared Browser runtime rejects bundled browser-service during trusted RPC validation #39407
   • [Windows] Browser/Chrome plugin fails trusted RPC dependency path validation #39399

   Powered by Codex Action
3. loritextile-coder commented on Aug 24, 2026

   

   loritextile-coder

   on Aug 24, 2026 – with ChatGPT Codex Connector

   Author

   More actions

   I reviewed the suggested duplicates.

   This is the same trusted-RPC failure family, but I am keeping this issue open because it is a fresh reproduction after the earlier reports were closed as completed:

   • Codex built-in browser plugin initialization fails: Trusted RPC dependency is not within a trusted code path #39136 was closed as completed on August 23.
   • [Windows 26.814] Browser and Chrome control stopped after morning component update #39305 covers the older 26.814 plugin rollout and was closed as a duplicate.
   • [Windows 26.818] Built-in Browser fails trusted RPC dependency validation #40405 reproduces the browser error on plugin 26.818.41509 and is already closed as completed.
   • This report reproduces the failure on the newer Windows Desktop package 26.818.8289.0 with bundled plugin 26.818.61809, after a confirmed full app restart.
   • In addition to Browser/Chrome, Computer Use now fails during initialization with Trusted RPC package must resolve within a configured trusted module directory: @oai/sky/service.

   The newer plugin/runtime version and the simultaneous Computer Use failure suggest a regression or incomplete trusted-module registration after the newer automatic update.
4. zemeng5208 commented on Aug 24, 2026

   

   zemeng5208

   on Aug 24, 2026 – with ChatGPT Codex Connector

   More actions

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

   This looks close enough to WinBridge’s current Windows local-repair scope to be worth checking, specifically the layer between the newly staged bundled plugin set and the user-side trusted runtime state after the automatic update.

   For this report, the useful local checks are:

   • whether ~/.codex/plugins/cache/openai-bundled/{browser,chrome,computer-use} contains one complete immutable version matching the new 26.818.61809 bundle rather than a partially materialized mix;
   • whether each plugin’s latest link/junction resolves to that complete version;
   • whether the bundled marketplace/staging metadata and the active plugin cache agree on the same version;
   • whether the user-side cua_node / node_repl runtime/helper paths used by the new bundle still resolve to the currently installed files rather than an older relocated runtime;
   • for Chrome specifically, whether the Native Host manifest, HKCU registration, schema-v1 host config, and chrome-native-hosts-v2.json entries all point to current existing binaries/resources and current browser-client trust data.

   WinBridge can diagnose and, where the inconsistency is in those user-writable local layers, rebuild/reconcile that state without modifying the signed WindowsApps package.

   Important limitation: the errors in this issue may also be an upstream regression in how Desktop 26.818.8289.0 launches trusted RPC services or constructs the trusted module/code-path environment for plugin 26.818.61809. If the bundled cache, latest, relocation targets, and Chrome native-host/v2 state are already internally consistent and match the installed package, then this is outside what WinBridge can reliably repair and needs an upstream fix. I would not treat a successful local-state repair as guaranteed for this report.
5. alfatrademarks-creator commented on Aug 29, 2026

   

   alfatrademarks-creator

   on Aug 29, 2026

   More actions

   Additional longitudinal reproduction: Trusted RPC failure continues across later Windows Browser component generations

   Adding a longer-term Windows data point to this issue.

   I previously reported the same Trusted RPC failure family in #39136:

   • initial independent reproduction: Codex built-in browser plugin initialization fails: Trusted RPC dependency is not within a trusted code path #39136 (comment)
   • follow-up after the next Desktop/Browser update: Codex built-in browser plugin initialization fails: Trusted RPC dependency is not within a trusted code path #39136 (comment)

   That earlier issue was later closed as completed. Since then, I have continued tracking Browser Use across multiple newer bundled component generations, and the failure has either persisted or reappeared after automatic updates.

   Earlier controlled reproductions

   August 18

   Environment:

   • Windows 11
   • Codex Desktop 26.814.5167.0
   • Browser 26.814.41407

   Both the built-in Browser and external Chrome control failed before browser/tab discovery with:

   Trusted RPC dependency must resolve within a configured trusted code path

   for the bundled browser-service.mjs.

   No website content or authentication state was reached before the failure.

   August 19

   After updating to:

   • Codex Desktop 26.814.5517.0
   • Browser 26.814.41957

   the same Trusted RPC failure was reproduced under the normal permission profile, again before browser discovery.

   I also ran a controlled permission A/B test on that environment:

   Normal workspace permissions
   → Browser runtime initialization failed with the Trusted RPC error.

   Full Access
   → the Browser runtime initialized successfully;
   → the built-in Browser opened example.com;
   → URL, page title, and H1 (Example Domain) were read programmatically;
   → the test tab was then closed.

   This confirmed Full Access as a workaround in that specific environment, but not as an acceptable steady-state solution.

   Browser access should not require disabling the normal sandbox boundary merely to initialize an official bundled service.

   Later Browser component checkpoints

   Since the original 26.814.41407 reproduction, the Browser component has moved through at least these observed package/build checkpoints:

   • 26.814.41957
   • 26.818.21641
   • 26.818.31338
   • 26.818.61809
   • 26.820.60940
   • 26.820.71523
   • 26.825.32147
   • 26.825.41651

   I am listing these as observed component generations, not as eight separate Desktop installations or eight identical controlled A/B tests.

   There was also a temporary interval after an intermediate update in which normal-permission Browser Use appeared to work in other tasks. I do not have a controlled build-specific A/B for that observation, so I am not treating it as proof of a particular fixed version.

   That pattern is independently consistent with this issue's stronger version-to-version reproduction: 26.818.41509 worked earlier in the day, then the automatic update to 26.818.61809 caused Trusted RPC initialization to fail again.

   August 28 controlled reproduction

   Environment:

   • Codex Desktop 26.825.4187.0
   • Browser 26.825.32147

   Under the normal permission profile:

   1. browser-client.mjs imported successfully.
   2. setupBrowserRuntime() then failed before a browser or tab could be obtained.
   3. The failure was again the Trusted RPC rejection of the bundled browser-service.mjs.
   4. No page data was read.

   This is important because the client module itself could load; the failure remained at trusted service initialization.

   Current August 29 environment

   Current installed versions:

   • Codex Desktop 26.825.5331.0
   • Browser / Chrome / Computer Use 26.825.41651
   • bundled CLI 0.151.0-alpha.7.1

   The current owner-side observation is that normal-permission Browser Use is still not operational and Full Access remains the practical workaround.

   I have not captured a fresh complete Trusted RPC trace from 26.825.41651 in this reporting session yet, so I am deliberately not claiming an exact error string for that build until another clean trace is recorded.

   What has been established in earlier controlled tests

   Across the earlier reproductions:

   • the bundled browser-service.mjs existed and was readable;
   • its service path was physically inside the configured trusted root;
   • the trusted runtime still rejected the service as outside the trusted code path;
   • browser initialization failed before site access, authentication, CDP, or tab inspection;
   • restart and manual trust/hash/path configuration experiments did not provide a durable normal-permission fix;
   • Full Access changed the outcome in a controlled A/B test.

   These observations make a target website or Chrome authentication state an unlikely immediate cause of this failure.

   Root-cause boundary

   Community investigations have proposed several related mechanisms, including:

   • trusted roots not being propagated correctly to a child trusted-service process;
   • Windows path normalization / sandbox identity handling;
   • trusted runtime environment reconstruction during plugin initialization.

   I am not presenting any of these as an official OpenAI root cause.

   Operational impact

   For my workflow, Browser Use is not primarily a UI-clicking convenience. It is a read-only acquisition layer for authorized web interfaces where public Web access or APIs are insufficient.

   Scheduled workflows use it to:

   1. access an already-authorized page;
   2. collect a point-in-time analytical snapshot;
   3. retain successive observations;
   4. pass the accumulated history into later analysis.

   When Browser Use stops after an automatic component update, the result is not just an interrupted interactive task. It can create gaps in historical time-series data that cannot necessarily be reconstructed later.

   Public Web access, APIs, external scraping tools, and manual transfer are useful partial fallbacks, but they do not replace access to an existing signed-in UI session.

   Expected behavior

   The official bundled Browser service should initialize under the normal permission profile.

   Website permissions should control which sites the agent may access. A user should not need to enable Full Access — which broadens filesystem and other sandbox permissions far beyond the browser task — simply for the official bundled Browser runtime to trust its own service.

   Request to maintainers

   Could you please confirm:

   1. which current Windows Desktop / Browser component combination is expected to contain the normal-permission fix for this Trusted RPC failure family;
   2. whether the recurrence across later automatic component updates is a known regression;
   3. what additional safe, read-only, sanitized diagnostics would be most useful from an affected 26.825.5331.0 / 26.825.41651 installation.

   I can provide another fresh trace from the current build if maintainers specify the preferred diagnostic boundary. No credentials, cookies, authenticated page contents, private paths, project identifiers, or conversation/thread IDs need to be included.
6. xiujiayou888-xiuxiu commented on Oct 12, 2026

   

   xiujiayou888-xiuxiu

   on Oct 12, 2026 – with ChatGPT Codex Connector

   Last edited by xiujiayou888-xiuxiu

   More actions

   Windows Computer Use: trusted service initialization fails

   Additional independent reproduction, checked 2026-10-12.

   Expected and actual result

   Expected: the official Computer Use plugin can enumerate Windows applications under normal workspace permissions.

   Actual: importing the official client succeeds, but sky.list_apps() fails before returning any windows:

   Trusted RPC package must resolve within a configured trusted module directory: @oai/sky/service
   

   Environment

   • Windows, x64.
   • Store package: OpenAI.Codex version 26.1007.2314.0.
   • Running desktop/plugin version: 26.1007.21434, production channel.
   • Bundled Codex Doctor: 0.162.0-alpha.17.2.
   • Bundled Node: 24.21.0; @oai/sky: 0.7.6.
   • Normal restricted workspace permissions; no Full Access or sandbox bypass used to control applications.
   • Configured Windows sandbox: elevated.
   • A prior compatibility attempt set features.prefer_mxc=false; this did not resolve the failure.
   • Correction (2026-10-12): a read-only CLI check with an empty temporary configuration reported prefer_mxc=false, but this does not establish the desktop app's automatic selection. Official Windows sandbox documentation states that the desktop app automatically prefers MXC on supported consumer devices: https://learn.chatgpt.com/docs/windows/windows-sandbox . The earlier inference that removing the override would not affect desktop behavior was unsupported. No rollback has yet been applied; no claim of a fix is made.
   • The runtime's logical C-drive installation path traverses a junction to a physical D-drive path. Causation is unknown.

   Minimal reproduction

   In the official node_repl tool, reset the kernel, then run:

   if (!globalThis.sky) {
     const { sky } = await import('@oai/sky');
     globalThis.sky = sky;
   }
   nodeRepl.write(await sky.list_apps());

   The error occurs before target app selection, authentication, screenshots, or input actions.

   Completed checks

   1. Confirmed the runtime module directory and @oai/sky/service export exist.
   2. Confirmed the configured module and trusted-code roots include the official runtime node_modules directory.
   3. Completed a full desktop restart and verified newly started processes. The failure persisted.
   4. Removed and reinstalled only computer-use@openai-bundled through official plugin tools. Installation and enabled-state checks passed; the failure persisted after a fresh JS kernel.
   5. Desktop logs before and after plugin reinstall still selected the same copied Node/node_repl runtime generation. Reinstalling the plugin did not demonstrate replacement of the shared runtime.
   6. In the ordinary node_repl JS kernel, an isolated mirror of service resolution and path containment succeeded. This is not the separate trusted worker and is not a successful Computer Use test.
   7. In a separate restricted shell probe, native realpath returned EPERM for the runtime and other directories. The same read-only probe, approved for one external-to-sandbox diagnostic invocation, passed. Neither probe imported the service or performed desktop control.
   8. A mirror that included the resolver hook failed at root canonicalization in the restricted shell, before package resolution; it passed in the approved read-only comparison. This does not reveal the exact hidden error inside the live trusted worker.
   9. Official update check reported up_to_date. Official Doctor additionally reported an unreachable desktop/runtime CDN and a WebSocket timeout; neither is established as the cause of the local trusted-service error.

   Current uncertainty

   The observed resolveTrustedService implementation catches errors from canonicalizing and resolving candidate roots, then emits the generic trusted-module error. No original caught error from the actual trusted worker has been obtained. Missing environment propagation, sandbox path accessibility, and path normalization remain hypotheses, not confirmed root causes.

   No trust-validation code, signed package, helper protocol, ACL, antivirus, or firewall has been modified. No private conversation, credentials, exact user paths, thread IDs, or target-window contents are included here.

   Request to maintainers

   Related open report: #40411

   Please provide either:

   1. A supported diagnostic switch that reports the original service-resolution error code and failing phase in the trusted worker without exposing secrets or relaxing validation; or
   2. A verified Windows desktop/shared-runtime combination or supported repair procedure for this failure under normal workspace permissions.

   Acceptance: official sky.list_apps() returns windows and a selected ordinary app can be inspected through sky.get_window_state, without disabling sandboxing or trusted-path validation.