Repository navigation
[macOS][Chrome extension][regression] Browser controls no longer working #39972
Description
What version of the ChatGPT/Codex app are you using?
ChatGPT desktop 26.818.31338 (build 6892), bundled Chrome plugin/native host 26.818.31338.
What platform are you using?
macOS 26.6.2 (build 25G83), arm64.
What issue are you seeing?
The official ChatGPT Chrome extension can read the active tab's URL, title, and visible text, but a side-panel session cannot initialize interactive Chrome control. Clicking, typing, navigation, opening result cards, following redirects, and observing newly opened tabs are unavailable. The session reports a capability state equivalent to: the native host did not provide a browser-client path / the host is out of date.
Static diagnostics do not indicate a missing or disabled installation:
- Google Chrome 151.0.7922.170 is running.
- ChatGPT Chrome extension
1.2.27268.51612_0is installed, registered, and enabled in the selected profile. - Bundled
check-native-host-manifest.js --browser chrome --jsonpasses withcorrect: trueandproblem: null. - The
chrome/latestsymlink resolves to plugin version26.818.31338. - The current schema-v2 runtime entry reports app/CLI/native-host version
26.818.31338, protocol 2, and valid paths for both:chrome/latest/scripts/browser-client.mjschrome/latest/scripts/browser-service.mjs
- The current runtime entry has a same-day
lastSeenAttimestamp. - Active-tab text extraction succeeds in the affected thread.
This looks like runtime capability discovery/native-host handshake failure: the active side-panel thread is not receiving or accepting the current registry entry's browser-control paths even though the text-context channel works.
Steps to reproduce
- Launch ChatGPT desktop 26.818.31338 and Chrome.
- Confirm the official ChatGPT extension is enabled.
- Open an ordinary authenticated site in Chrome.
- Open the ChatGPT extension side panel.
- Ask the side-panel thread to read the selected tab; URL, title, and visible text are returned.
- Ask it to click a link, navigate, open a result card, or observe a new tab.
- Interactive control is unavailable and the thread reports that the native host did not provide the browser-client path / is out of date.
The failure occurs before any website-specific action. It is not caused by a CAPTCHA, sign-in prompt, or site permission.
Expected behavior
A fresh side-panel thread should initialize interactive Chrome control when Chrome, the official extension, and the matching native host are installed and connected. If the handshake fails, the UI should expose the selected runtime entry and exact rejected/missing capability instead of recommending reinstall/update when packaged versions and paths already match.
Diagnostic details
Bundled read-only checks:
chrome-is-running.js --browser chrome --check: passinstalled-browsers.js --json: passcheck-extension-installed.js --browser chrome --json: passcheck-native-host-manifest.js --browser chrome --json: pass
The v2 registry retains one older runtime entry (26.623.141536, last seen 2026-07-07) in addition to the current 26.818.31338 entry. It is unclear whether entry selection or registry hydration contributes.
Suggested investigation areas:
- Schema-v2 runtime entry selection when historical entries remain.
- Cache/race behavior between native-host registration, side-panel startup, and per-thread capability snapshots.
- Why the thread reports a missing browser-client path when the current registry entry contains a valid one.
- Whether text-context and interactive-control channels initialize independently.
- Add a supported diagnostic exposing the exact handshake/capability failure.
Impact
Authenticated Chrome workflows are blocked even though page reading works. The observed workflow required opening search results, capturing post-redirect destination URLs, restoring the original search, inspecting new tabs, and advancing pagination. No form fields were entered and no external action was submitted.
No account data, cookies, credentials, local usernames, query parameters, or page contents are included here.
Related issue
Closely matches #39531, but that report is Windows-specific. This is a macOS reproduction where the extension, manifest, current native-host version, and current schema-v2 browser-client paths all validate successfully.
Support case number
Support case #: 13795795
Activity
github-actions commentedon Aug 21, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
akkikumar72 commentedon Aug 25, 2026
Facing the same issue for the past 3/4 days. Did we get any fix for it?
bryndonhumphrey commentedon Aug 25, 2026
@akkikumar72 haven't heard anything yet and the issue is still happening for me.
Just opened this bug report in the openai discord
https://discord.com/channels/974519864045756446/1541835402350956614
bryndonhumphrey commentedon Aug 25, 2026
@johnl-oai saw your name on a closed codex+chrome bug, which was reported in discord.
Is there anything we can do to prioritize getting this feature fixed? It is massively helpful.
I use it all the time in a codex+chrome+google sheets driven job hunting workflow.
I'd be devastated if this functionality never comes back.
https://github.com/bryndonhumphrey/codex-job-search-workflow/blob/main/README.md
akkikumar72 commentedon Aug 26, 2026
I can confirm that this appears to be a recent regression. I had been using the Codex Chrome integration regularly without issues, but interactive browser control suddenly stopped working around three to four days ago. Reading page content still works, while actions such as clicking, typing, and navigation are no longer available.
[-][macOS][Chrome extension] Side panel stays read-only although native-host and browser-client diagnostics pass[/-][+][macOS][Chrome extension][regression] Browser controls no longer working[/+]sandipb commentedon Aug 27, 2026
I faced the same problem and root caused it to a clash with a separate skill I installed - agent-browser. Its description is overriding the routing of the agent to that skill for any browser interaction.
If I use this explicit instruction in the chrome extension session, it works.
It is possible that the problem is not the agent-browser skill but the inbuilt "browser:control-in-app-browser" skill itself.
pych-ky commentedon Aug 28, 2026
I reproduced a matching split state with the official Google Chrome on macOS: current-tab reads worked, while click/type/navigation were unavailable and the side panel reported a missing browser-client path / outdated native host.
In my reproduction, the captured native-host runtime config contained a valid
browserClientPathbut no owntrustedBrowserClientSha256sproperty. Passing that captured object to the unmodified extension build's actual runtime-config parser returnednull, so the valid path was discarded as a consequence of schema rejection. After a version-specific local parser compatibility change, the path was retained and interactive Chrome control worked again.I posted the parser-level evidence, exact minimal diff, verification, and unsupported local-workaround warnings in #40823. This should only be treated as the same failure if the affected environment shows the same signature: a valid host-provided
browserClientPath, an absent trust-list property, and whole-object parser rejection. The generic outdated-host message can also be caused by installation, registration, routing, profile-selection, or other failures.akkikumar72 commentedon Aug 28, 2026
I gave up and switched to Claude extension Will get back if they fix this issue in future.
bryndonhumphrey commentedon Aug 28, 2026
Thank you @sandipb — your explicit-routing workaround fixed this for me.
What worked:
For automated skills, I also added a preflight that lists and claims the Chrome tab and performs a read-only DOM operation. Reading the current tab’s text alone is not enough to prove interactive control is available.
After these changes, clicking, navigation, and tab control worked again. I did not modify the managed Chrome extension, inject hashes, or change the native-host registry. Hopefully this gives future readers a safe workaround while the underlying routing/runtime issue is addressed upstream.
Thanks again for identifying the routing collision, and thanks @pych-ky for the detailed runtime-config investigation.