Skip to content

OpenAI Support Diagnostic: Browser and Chrome Runtime Bootstrap Failure #39252

Open

Description

@ElleJaeKayArt-spec

OpenAI Support Diagnostic: Browser and Chrome Runtime Bootstrap Failure

Suggested support ticket subject

ChatGPT desktop on Windows rejects bundled Browser service as outside trusted code path

Summary

The ChatGPT/Codex desktop app cannot initialize either the built-in Browser or
the Chrome extension control surface. Both fail before browser discovery, tab
selection, URL navigation, or website permission checks.

The exact error is:

Trusted RPC dependency must resolve within a configured trusted code path: file:///C:/Users/Maui%20JM%20Photography/.codex/plugins/cache/openai-bundled/browser/26.814.41407/scripts/browser-service.mjs

The target file exists on disk. The same failure occurs when initialization is
started through the Browser plugin and through the Chrome plugin.

Impact

  • The built-in Browser cannot initialize.
  • The Chrome connection cannot be queried or validated.
  • Localhost UI testing cannot begin.
  • No webpage was reached, and no browser action was performed.

Environment

Diagnostic captured: 2026-08-18T13:56:43.9393520-04:00

Component Observed value
Operating system Microsoft Windows 10, version 10.0.19045.7663, x64
Desktop package path version OpenAI.Codex_26.814.5167.0_x64__2p2nqsd0c76g0
Desktop executable ChatGPT.exe
Desktop executable file/product version 151.0.7922.137
Browser plugin OpenAI bundled browser, version 26.814.41407
Chrome plugin OpenAI bundled chrome, version 26.814.41407
Browser service path C:\Users\Maui JM Photography\.codex\plugins\cache\openai-bundled\browser\26.814.41407\scripts\browser-service.mjs

The application package version and plugin version are different. That may be
normal versioning, but it is relevant because the failure is specifically a
trusted-code-path rejection at the plugin boundary.

Reproduction: built-in Browser

  1. Open this task in the ChatGPT desktop app on Windows.
  2. Ask Codex to check the internal Browser connection or invoke @Browser.
  3. Codex loads the documented Browser client from the absolute installed path:
    ...\browser\26.814.41407\scripts\browser-client.mjs.
  4. The runtime attempts to initialize the built-in Browser selector (iab).
  5. Initialization stops immediately with the trusted RPC dependency error
    above.

Expected: the Browser runtime initializes and returns a built-in Browser
binding.

Actual: initialization fails before the Browser selector can be queried.

Reproduction: Chrome

  1. Ask Codex to check the Chrome connection or invoke @Chrome.
  2. Codex loads the documented Chrome client from the absolute installed path:
    ...\chrome\26.814.41407\scripts\browser-client.mjs.
  3. The runtime attempts to initialize the Chrome selector.
  4. Initialization stops with the same rejection of the shared Browser plugin
    service path.

Expected: the runtime initializes and reports whether the ChatGPT Chrome
extension is connected.

Actual: initialization fails before Chrome discovery, so extension status is
unknown.

Repetition and isolation results

  • The failure reproduced repeatedly in this task.
  • It reproduced with an explicit built-in Browser selector.
  • It reproduced with an explicit Chrome selector.
  • It reproduced when localhost was the intended target.
  • It occurred before any URL, login, browser profile, tab, site permission,
    cookie, or local-storage access.
  • The Chrome plugin directory metadata changed during troubleshooting, but the
    same plugin version and failure remained. The diagnostic does not assume
    which user or application action caused that metadata change.

These results make a localhost application bug, authentication problem, site
allowlist problem, and ordinary Chrome-extension disconnection unlikely as the
immediate cause.

File integrity evidence

All required files below exist and were readable.

File Bytes SHA-256
Browser scripts/browser-client.mjs 147,953 3B9D8DCC6DC968887E8A969C63DAE6380E3C1C59FF5C474EB32DF08C353DAD87
Browser scripts/browser-service.mjs 1,250,004 B6FD7F485FDF59CC4A25445479545B24972F6226C79C72AB7BD985D86F069615
Chrome scripts/browser-client.mjs 147,953 3B9D8DCC6DC968887E8A969C63DAE6380E3C1C59FF5C474EB32DF08C353DAD87

The Browser and Chrome client files are byte-identical by SHA-256, and both
resolve to the shared Browser service that is rejected.

Working hypothesis

Strong hypothesis: the desktop app's trusted RPC/module configuration does not
recognize the installed bundled Browser service path as trusted, possibly due
to an application/plugin cache version mismatch or packaging/configuration
error.

This is not claimed as a proven root cause. The error occurs inside the
OpenAI-bundled runtime before browser discovery, and the agent cannot inspect
the desktop app's internal trust configuration.

Requested support investigation

Please check:

  1. Whether desktop package 26.814.5167.0 is compatible with bundled Browser
    and Chrome plugin version 26.814.41407.
  2. Whether the trusted-code roots supplied to the browser-control runtime
    include the installed cache path for browser-service.mjs.
  3. Whether the plugin cache should be invalidated and repopulated with a newer
    compatible build.
  4. Whether the SHA-256 values above match the expected published artifacts.
  5. Whether a desktop app update or server-side plugin rollout is required.

Privacy and safety notes

  • No secrets, tokens, cookies, browser history, local storage, or credentials
    were inspected or included.
  • No checkout action, payment action, Etsy action, website submission, or other
    external write occurred.
  • The Windows profile name appears only because it is part of the exact path in
    the runtime error.

How to attach the affected task

In the ChatGPT desktop app, type / in the message composer and choose the
feedback option. When prompted, attach/share this existing task so support can
receive the session evidence and provide a session ID.

Official references:

Session-close declaration

No standards changes this session.

Activity

  1. added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    skillsIssues related to skills
    on Aug 18, 2026
  2. invizijars-lab commented on Aug 18, 2026

    @invizijars-lab

    Independent reproduction on Windows:

    • OS: Windows 11 Pro, build 10.0.26200 (x64)
    • ChatGPT/Codex desktop package: 26.814.5167.0
    • Bundled Codex CLI: 0.148.0-alpha.15
    • OpenAI-bundled Browser plugin: 26.814.41407
    • Built-in Browser fails during runtime initialization, before any page or tab access, with:
      Trusted RPC dependency must resolve within a configured trusted code path: file:///%USERPROFILE%/.codex/plugins/cache/openai-bundled/browser/26.814.41407/scripts/browser-service.mjs

    Additional observations:

    1. The referenced browser-service.mjs file exists on disk.
    2. The Browser plugin was refreshed/reinstalled through the supported codex plugin add browser@openai-bundled command.
    3. Codex was then fully exited and restarted.
    4. The same trusted-code-path error still reproduced immediately.
    5. codex doctor --json reported installation, config loading, MCP configuration, auth, network reachability, WebSocket reachability, runtime, and state databases as healthy. Its only failing check was terminal.env because the diagnostic was launched non-interactively with TERM=dumb, which appears unrelated.
    6. No website, Google account, browser profile, cookies, or page permissions were reached or inspected.

    This independently supports the issue's hypothesis of a desktop/plugin trust-boundary or packaging mismatch rather than a site-specific problem. No session logs or user-specific paths are included.

  3. adamczhang commented on Aug 18, 2026

    @adamczhang

    Confirmed community downgrade workaround

    Cross-referencing the original workaround from #39136:

    Affected users report that downgrading the Windows desktop app from 26.814.5167.0 to 26.810.7004.0, then clearing the cached Browser and Chrome plugin folders, restores browser control:

    %USERPROFILE%\.codex\plugins\cache\openai-bundled\browser
    %USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome
    

    The official Store-signed x64 installer is available through OpenAI’s Windows deployment page:

    https://learn.chatgpt.com/docs/enterprise/windows-deployment

    Because that download URL is rolling and is not permanently pinned to 26.810.7004.0, affected users may want to download and preserve the currently working installer immediately. After recovery, decline the offered update until OpenAI confirms the 26.814 Browser/Chrome trusted-RPC regression is fixed.

    This is a community workaround, not an official fix. Back up relevant local state before deleting plugin caches.

  4. xMythicx commented on Aug 31, 2026

    @xMythicx

    @ElleJaeKayArt-spec @invizijars-lab @adamczhang

    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 past the blocker.

  5. xMythicx commented on Aug 31, 2026

    @xMythicx

    @ElleJaeKayArt-spec , @invizijars-lab , @adamczhang , 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 .

    Global config.toml
    ~/your-home-dir/.codex/config.toml
    
    default_permissions = "safe-workspace"
    
    [permissions.safe-workspace]
    description = "Workspace access with selected sensitive personal paths denied."
    extends = ":workspace"
    
    [permissions.safe-workspace.filesystem]
    # Personal folders that are not current project locations
    "~/Desktop" = "deny"
    "~/Downloads" = "deny"
    "~/Movies" = "deny"
    "~/Music" = "deny"
    "~/Pictures" = "deny"
    
    # Sensitive macOS application data
    "~/Library/Accounts" = "deny"
    "~/Library/AddressBook" = "deny"
    "~/Library/Calendars" = "deny"
    "~/Library/Mail" = "deny"
    "~/Library/Messages" = "deny"
    "~/Library/Mobile Documents" = "deny"
    "~/Library/Safari" = "deny"
    
    # Codex authentication material
    "~/.codex/auth.json" = "deny"
    

    Then my project level config , extends this profile

    model = "gpt-5.6-sol"
    model_reasoning_effort = "medium"
    approval_policy = "on-request"
    approvals_reviewer = "user"
    
    [permissions.custom-profile]
    description = "Coordinate registered repositories while sensitive personal paths remain denied."
    extends = "safe-workspace"
    
    [permissions.custom-profile.filesystem]
    Redacted system file paths
    
    [permissions.custom-profile.workspace_roots]
    "path-to-project" = true
    
    [permissions.custom-profile.network]
    enabled = true
    
    [permissions.custom-profile.network.domains]
    "github.com" = "allow"
    "api.github.com" = "allow"
    "objects.githubusercontent.com" = "allow"
    "raw.githubusercontent.com" = "allow"
    "codeload.github.com" = "allow"
    "chatgpt.com" = "allow"
    
    [agents]
    max_concurrent_threads_per_session = 5
    
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbrowserbugSomething isn't workingskillsIssues related to skillswindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions