openai / openai/codex

In-app Browser intermittently fails on Windows with “Trusted RPC dependency must resolve within a configured trusted code path”

Open
#39,302 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

app app-server browser bug windows-os
Dominant language
Rust
Stars
125k
Forks
19.4k
PR merge metrics
PR metrics pending

Description

What version of the Codex App are you using (From “About Codex” dialog)?

Codex CLI/runtime: 0.148.0-alpha.15

What subscription do you have?

Plus

What platform is your computer?

Windows11 Pro actual patch level

What issue are you seeing?

Title: In-app Browser intermittently fails on Windows with “Trusted RPC dependency must resolve within a configured trusted code path”
Environment:
• Windows 11
• ChatGPT/Codex Desktop App: 26.814.5167.0
• Browser plugin: 26.814.41407
• Codex CLI/runtime: 0.148.0-alpha.15
• Node REPL runtime:
C:\Users\raeto\AppData\Local\OpenAI\Codex\runtimes\cua_node\2fb562745e6d66f0\bin\node_repl.exe
Problem:
The built-in ChatGPT/Codex browser on Windows fails during browser runtime initialization.
The error is consistently:
Trusted RPC dependency must resolve within a configured trusted code path: file:///C:/Users/raeto/.codex/plugins/cache/openai-bundled/browser/26.814.41407/scripts/browser-service.mjs
The issue affects the in-app browser and prevents normal browser automation. The browser occasionally works once after a reset or configuration change, but subsequent attempts fail again.
Expected behavior:
The built-in browser should initialize normally and allow pages such as https://example.com/ to be opened and inspected.
Actual behavior:
browser-client.mjs can be imported, but setupBrowserRuntime() fails when it attempts to initialize the trusted browser service.
The Browser plugin itself is present and loaded from:
C:\Users\raeto.codex\plugins\cache\openai-bundled\browser\26.814.41407
The runtime repeatedly fails specifically when resolving:
...\scripts\browser-service.mjs
Relevant configuration:
The generated C:\Users\raeto.codex\config.toml contains:
NODE_REPL_TRUSTED_CODE_PATHS = 'C:\Users\raeto.codex;C:\Users\raeto\AppData\Local\OpenAI\Codex\runtimes\cua_node\2fb562745e6d66f0\bin\node_modules'
BROWSER_USE_AVAILABLE_BACKENDS = "chrome,iab"
BROWSER_USE_CODEX_APP_VERSION = "26.814.41407"
NODE_REPL_TRUSTED_SERVICES = '{"browser":"C:/Users/raeto/.codex/plugins/cache/openai-bundled/browser/26.814.41407/scripts/browser-service.mjs","sky":"@oai/sky/service"}'
NODE_REPL_TRUSTED_BROWSER_CLIENT_SHA256S = "8e172ec9f458f2e636fc69a1b8c68c217f6bb8d10c41f70a05a0878b73863701"
The configuration therefore explicitly declares the browser service as trusted and points to the same browser plugin version that is being loaded.
Runtime observation:
The Codex sandbox process also receives filesystem read permission for:
C:/Users/raeto/.codex/plugins/cache/openai-bundled/browser/26.814.41407/scripts
so this does not appear to be a normal filesystem sandbox permission failure.
However, when inspecting the environment available inside a running node_repl, the following values were observed:
process.env.NODE_REPL_TRUSTED_CODE_PATHS → undefined
process.env.NODE_REPL_TRUSTED_SERVICES → undefined
process.env.BROWSER_USE_AVAILABLE_BACKENDS → undefined
process.env.BROWSER_USE_CODEX_APP_VERSION → undefined
while:
process.env.NODE_REPL_TRUSTED_BROWSER_CLIENT_SHA256S
was correctly populated with:
8e172ec9f458f2e636fc69a1b8c68c217f6bb8d10c41f70a05a0878b73863701
This suggests that only part of the browser/trust environment is reaching the active Node REPL runtime.
Reproduction:

  1. Start ChatGPT/Codex Desktop on Windows.
  2. Start a local Codex/Work session.
  3. Ask:
    Open the built-in browser. Open example.com and return only the page title.
  4. Browser initialization fails with:
    Trusted RPC dependency must resolve within a configured trusted code path ... browser-service.mjs
  5. Repeating the operation in another window or session produces the same failure.
    Intermittent behavior:
    After performing a full ChatGPT Desktop reset, the browser worked once and successfully returned the title Example Domain.
    Shortly afterwards the failure returned.
    A later manual configuration test also resulted in one successful browser initialization followed by repeated failures.
    This makes the issue appear related to per-session or per-node_repl initialization rather than the browser files themselves.
    Troubleshooting already performed:
    • Windows App “Repair”
    • Full ChatGPT Desktop Reset
    • Complete ChatGPT Desktop uninstall/reinstall
    • Browser plugin cache removed/renamed and automatically regenerated
    • Verified browser plugin files exist
    • Verified browser-service.mjs exists
    • Verified multiple ChatGPT/Codex processes are responsive
    • Disabled/removed external ChatGPT/Codex Chrome/Edge/Brave browser extensions to exclude interference
    • Verified the built-in Codex process is started by the ChatGPT Desktop app
    • Verified sandbox filesystem permission includes the Browser plugin scripts directory
    • Temporarily added the exact browser scripts directory to NODE_REPL_TRUSTED_CODE_PATHS
    • Temporarily made config.toml read-only to prevent automatic rewriting
    None of these changes produced a stable fix.
    Important finding:
    Even though config.toml contains the Browser trusted-service and trusted-path configuration, several corresponding environment values are undefined inside the running node_repl.
    The failure therefore appears to occur between:
    ChatGPT/Codex app-server
    → node_repl initialization
    → trusted RPC service registration
    rather than in Chrome, Edge, networking, page access, or the Browser plugin files themselves.
    Possible root cause:
    There may be a bug in the Windows ChatGPT/Codex Desktop runtime where the browser/trusted-service environment is not consistently propagated into newly created node_repl instances.
    This would explain:
    • why the browser can occasionally work once,
    • why later sessions fail,
    • why browser-service.mjs is readable but still rejected by the trusted RPC validator,
    • and why only NODE_REPL_TRUSTED_BROWSER_CLIENT_SHA256S appears inside the active REPL while the other Browser/Trust variables are missing.
    Requested investigation:
    Please verify how these values are propagated from config.toml / app-server into the Windows node_repl runtime:
    • NODE_REPL_TRUSTED_CODE_PATHS
    • NODE_REPL_TRUSTED_SERVICES
    • NODE_REPL_TRUSTED_BROWSER_CLIENT_SHA256S
    • BROWSER_USE_AVAILABLE_BACKENDS
    • BROWSER_USE_CODEX_APP_VERSION
    Please also check whether ChatGPT Desktop 26.814.5167.0 and Browser plugin 26.814.41407 are expected to operate together and whether there is a known issue with trusted RPC path initialization across multiple Node REPL sessions on Windows.

Bei Fragen bitte fragen.

Mit freundlichen Grüßen
Tobias Rätz

Fon: +4915233621391
Web: https://www.raeto.com/

What steps can reproduce the bug?

Feedback ID: no-active-thread-01a016fb-ccd1-7173-b772-3e897c9a58b2

What is the expected behavior?

Browsing with cahtgpt desktop app works and grabbing information from chrome shown wesites is possible

Additional information

No response

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with config.toml and the browser-client.mjs setupBrowserRuntime() path, then inspect how app-server values reach the node_repl.exe environment on Windows. Compare the configured trust variables with those visible in the running REPL and reproduce the failure using the example.com browser request; done means the browser initializes consistently across new sessions.

Written by the indexing model from the issue text.

Assessment

Tech stack
node.js
Domain
desktop, tooling
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.