Repository navigation
Browser and Chrome plugins fail trusted-path validation on Windows after update #39502
Copy link
Copy link
Open
Labels
appIssues related to the Codex desktop appIssues related to the Codex desktop appbrowserbugSomething isn't workingSomething isn't workingwindows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems
Description
What version of the Codex App are you using (From “About Codex” dialog)?
Codex/ChatGPT desktop app build: 26.814.5167.0
What subscription do you have?
Pro Plan
What platform is your computer?
OS: Windows
What issue are you seeing?
Summary
After updating the Codex/ChatGPT desktop app, both the built-in Browser and Chrome control fail during initialization with a trusted-code-path error.
The Codex Chrome extension itself works: its side panel loads and can list open Chrome tabs. The failure occurs inside the desktop app before either browser-control runtime can initialize.
Error
Trusted RPC dependency must resolve within a configured trusted code path:
file:///C:/Users/<username>/.codex/plugins/cache/openai-bundled/browser/26.814.41407/scripts/browser-service.mjs
Environment
- OS: Windows
- Codex/ChatGPT desktop app build: 26.814.5167.0
- Browser plugin build: 26.814.41407
- Chrome plugin build: 26.814.41407
- Feedback/session/chat ID: 01a01a89-625c-79c0-b1b9-92ea6f3c9b8d
### What steps can reproduce the bug?
Steps to reproduce
1. Open the Codex desktop app.
2. Start a new task.
3. Ask Codex to use either @Browser or @Chrome.
4. Browser runtime initialization fails with the trusted-path error above.
### What is the expected behavior?
Expected behavior
Codex should initialize the selected browser runtime and connect to the built-in browser or Chrome.
### Additional information
Actual behavior
Both @Browser and @Chrome fail with the same trusted-path error before browser interaction begins.
Troubleshooting already completed
- Reinstalled the Chrome extension.
- Confirmed the Chrome extension is enabled in the correct Chrome profile.
- Confirmed the Chrome side panel loads and lists tabs.
- Removed and re-added the Chrome plugin in Codex.
- Fully restarted Chrome.
- Fully quit and restarted Codex.
- Restarted Windows.
- Reproduced the failure in multiple Codex tasks.
- Reproduced the failure with both @Chrome and @Browser.
- Ran /feedback immediately after reproduction.
- Verified the required browser-service.mjs file exists.
- Verified the Browser and Chrome bundled plugins are both version 26.814.41407.
The built-in Browser is bundled and does not appear as a removable plugin in this app build, so it cannot be separately reinstalled through Settings → Plugins.
Additional context
This does not appear to be a Chrome-extension connection problem or task-specific state. Both browser surfaces fail when the bundled Browser runtime attempts to load browser-service.mjs.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
appIssues related to the Codex desktop appIssues related to the Codex desktop appbrowserbugSomething isn't workingSomething isn't workingwindows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems
Activity
github-actions commentedon Aug 19, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
xMythicx commentedon Aug 31, 2026
@Andy-rateria
Ok so I believe this issue is perhaps related to project level config profiles when the global .codex/config.toml specifically sets sandbox_mode = "workspace-write". Removing this setting and creating a new task with the permission profile set to "ask for approval' seems to have fixed the RPC error for me, This raises more questions as I am using custom project level configuration profiles. Perhaps I need to move those rules up to global and just use the global config for now. As Open ai docs do state the project level permission are still in beta. Thought to share if others are hitting this wall too. It has impacted my productivity since the Aug 20 release , and thought this detail may help others get passed the blocker.
xMythicx commentedon Aug 31, 2026
@Andy-rateria , following up, What I have come to find through troubleshooting this RPC error is that it has to do with your permission profile hierarchy and boundaries. Set in your global config and in project-level config. Here is the thing that helped me get past this blocker . If either profile specifically has a setting for "
/your-home-dir" = deny , then this supersedes all later configured settings for attempts to access it. Even if you later have a custom subdirectory read permission . Example: "/your-home-dir/subpath" = "read" . That later setting seems to be discarded and the earlier deny is enforced. Yes, it seems odd, so Codex task needs access to your home directory from many processes it runs. How to give it controlled access without allowing it access to personal data? For me, I created a custom profile that extends :workspace, named it :safe-workspace, then white-listed all the custom paths in the home folder that I did not want the threads to access . Then my project-level permission profiles extend that safe workspace. Here is an example from my global ~/.code/config . This lets Codex access its needed directories inside the home folder while securing my personal directories. I have not been successful with any other configuration to restore Chrome or Browser. This also restored an issue I was having when sending messages from mobile and my permission profile was being downgraded. Hope this helps :), this took me weeks to sort, so hoping it’s helpful to others, the down side to this is you must explicitly list every private directory. But I have not found any other way .Then my project level config , extends this profile