[macOS][26.818.41509] Chrome control fails trusted RPC path validation under managed permissions

Open 💬 2 comments Opened Aug 23, 2026 by liby
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

Codex/ChatGPT Desktop 26.818.41509 (build 6962)

  • Bundled Browser plugin: 26.818.41509
  • Bundled Chrome plugin: 26.818.41509
  • Bundled Codex CLI: 0.149.0

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Darwin 25.5.0 arm64 arm

macOS 26.5.2 (build 25F84), Apple Silicon.

What issue are you seeing?

Chrome control cannot initialize under the managed development permission profile after removing only the explicit Browser cache read rule that was previously required as a workaround.

The active filesystem profile during the test was:

default_permissions = "development"

[permissions.development.filesystem]
":root" = "write"

[permissions.development.filesystem.":workspace_roots"]
".env" = "read"
".env.local" = "read"

The generated configuration still included the user's Codex home directory in NODE_REPL_TRUSTED_CODE_PATHS, and NODE_REPL_TRUSTED_SERVICES.browser pointed to the installed bundled Browser service. Chrome initialization nevertheless stopped before browser discovery with:

Trusted RPC dependency must resolve within a configured trusted code path: file:///Users/<redacted>/.codex/plugins/cache/openai-bundled/browser/26.818.41509/scripts/browser-service.mjs

No page was opened, so the requested example.com title was not available.

What steps can reproduce the bug?

  1. Start with the managed development permission profile shown above.
  2. Remove only this explicit local workaround from the live configuration:

``toml
"/Users/<redacted>/.codex/plugins/cache/openai-bundled/browser" = "read"
``

  1. Fully quit and restart Codex/ChatGPT Desktop.
  2. Create a new task.
  3. Confirm that the live filesystem permission table does not contain an explicit Browser cache read rule.
  4. Ask the bundled Chrome plugin to open https://example.com and return the page title.
  5. Observe that initialization fails with the trusted RPC path error above before Chrome discovery or navigation.

Fresh reproduction task ID: 01a02f73-b129-7183-b659-f44784b22b6f.

The test made one Chrome initialization attempt. It did not modify configuration, retry, or use another browser.

What is the expected behavior?

The bundled Chrome integration should initialize under the configured managed permission profile and open the requested page without requiring a user-added read rule for the bundled Browser service cache.

Additional information

This is a current macOS follow-up to #39136, whose primary report is Windows-scoped and is now closed. I previously documented the same macOS error and the controlled read-rule workaround in this comment.

Issue #39591 also reports a macOS Browser initialization failure, but its observed error is trusted Node process exited unexpectedly; this reproduction stops on the trusted RPC service-path validation error shown above.

After collecting the fresh-task result, the explicit Browser cache read rule was restored in the live configuration and the configuration passed strict parsing. No post-restore Browser or Chrome attempt is included in this report.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 4 days ago

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

  • #39136
  • #39502
  • #39486

Powered by Codex Action

carter-smalls · 4 days ago

Looks like trusted rpc dependency must resolve within a configured trusted code path error.

Use badgr-config-doctor to identifies missing or mis‑configured permission entries causing the trusted rpc error.

That should help confirm node_repl_trusted_code_paths missing browser cache read permission.

Run it now on Badgr →