ChatGPT Chrome sidebar is read-only and falsely reports an outdated native host

[Luisfelipeberchielli]

Summary

The official ChatGPT Chrome sidebar can read the active page and describe visible elements, but it cannot click, type, or navigate. It repeatedly claims that the Codex native host is outdated, even though all native-host diagnostics pass.

Browser control from a separate Codex desktop task can successfully claim the same Chrome tab and execute clicks. The failure is specific to the control interface exposed to sidebar conversations.

Environment

• macOS on Apple Silicon
• Google Chrome: 151.0.7922.174
• ChatGPT Chrome extension: 1.2.27268.51612
• Bundled Chrome plugin/native host: 26.818.41705
• Extension ID: hehggadaopoacecdllhhajmbjkdcmajg

Actual behavior

The sidebar can read the active page but refuses interactive operations with messages such as:

• “The native component of the Codex extension is outdated.”
• “This session only exposes page reading, without browser control.”
• “I cannot execute clicks or navigate in Meta Business.”

Reinstalling or updating the extension does not resolve the issue.

Diagnostics performed

• Chrome extension is installed and enabled in the Default profile.
• Native Messaging manifest exists and validates successfully.
• Manifest name, path, and allowed extension origins are correct.
• Native-host executable exists, is executable, ARM64, and signed by OpenAI.
• The native-host process was restarted after the plugin updated.
• A fresh extension connection was established.
• A separate Codex desktop task successfully claimed the same Meta Business tab and executed a test click.
• New sidebar conversations still receive only read access and incorrectly report that the native host is outdated.

Steps to reproduce

1. Install and enable the official ChatGPT Chrome extension.
2. Confirm that the native host and extension are connected.
3. Open an authenticated website such as Meta Business Suite.
4. Open the ChatGPT Chrome sidebar.
5. Ask it to click a visible link or button.
6. Observe that it reads the page correctly but refuses to interact, claiming the native component is outdated.
7. Start a new sidebar conversation and retry; the problem persists.

Expected behavior

When the extension and native host are connected and valid, sidebar conversations should receive the interactive Chrome-control interface and be able to click, type, and navigate.

If the control interface cannot be attached, the UI should report the actual backend or permission failure instead of incorrectly instructing the user to reinstall an already valid native host.

Workarounds attempted

• Reinstalled and re-enabled the Chrome extension.
• Restarted the native-host process.
• Restarted the sidebar.
• Created new conversations.
• Enabled browser control from the sidebar toolbar.
• Verified the latest bundled plugin and native-host versions.

Related issues

• Codex Chrome plugin shows Connected on Windows, but Codex cannot control Chrome and initialization times out #22264
• Chrome plugin backend unavailable despite extension showing Connected #25811
• Chrome plugin works in UI, but Codex browser bridge reports Browser is not available: chrome. #37307
• Browser plug in and chrome setting not working in the app #39211

Privacy

No account email, phone number, Meta account information, private URLs, screenshots, or authentication data are included.

[github-actions]

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

• [macOS][Chrome extension][regression] Browser controls no longer working #39972
• Windows: Chrome side panel cannot control tabs because browser-client path is reported missing despite valid native host #40077

Powered by Codex Action

[sternbj]

Reproduced again on macOS in the ChatGPT Chrome side panel on 2026-08-24.

• The side panel can read the selected authenticated tab through page context.
• A fresh retry still exposes no interactive Chrome control, so it cannot click, type, navigate, or save.
• The assistant reports that the native host did not provide a browser-client path and incorrectly recommends updating or reinstalling the plugin.
• The affected website is not blocked, and the authenticated page context remains readable throughout.
• The issue occurs in a separate active Chrome profile with the extension side panel loaded.

This matches the reported split state: page-reading works, while the interactive control interface is missing. No private page content, account identifiers, credentials, screenshots, or URLs are included here.

[sternbj]

Additional environment and retry details from another reproduction on 2026-08-24:

• Google Chrome: 151.0.7922.170
• ChatGPT desktop app: 26.818.41509
• macOS on Apple Silicon
• The exact installed Chrome-extension version is not exposed to the affected sidebar connection.
• After changing the selected tab from an authenticated accounting page to this GitHub issue, the sidebar metadata reported the GitHub URL and the same tab ID, but the page-context tool still returned the previous accounting page. This suggests stale tab binding/context in addition to the missing interactive-control interface.
• Logging out and back in could not be tested by the assistant because the same defect removes all click and typing capabilities.

No private page content, account identifiers, credentials, screenshots, or private URLs are included.

[sternbj]

New regression evidence from 2026-08-26:

Browser Use worked reliably until approximately 2026-08-24. The system-wide failure started only about two days ago without an intentional configuration change, so this now looks like a recent regression rather than a longstanding setup issue.

Current environment:

• ChatGPT desktop: 26.820.60940, build 7119
• Codex CLI: 0.150.0-alpha.8
• macOS 26.6.0 on Apple Silicon
• Google Chrome: 152.0.7977.64
• ChatGPT Chrome extension: 1.2.27268.51612_0

Additional isolation results:

• Current Codex tasks expose no node_repl or Chrome tool at all.
• The configured node_repl MCP executable starts successfully when tested directly.
• Its MCP tools/list response includes js, js_add_node_module_dir, and js_reset, so the local server itself is healthy.
• All packaged Chrome diagnostics pass: Chrome is running, the extension is installed/registered/enabled, and the native-host manifest and expected extension origins are correct.
• The installed browser client SHA-256 is 2158647076eed887c7591cca0957da78747ab9155819d64409d6b895e84ed99b.
• A stale trusted browser-client hash was corrected to that installed value.
• After a forced full ChatGPT desktop restart, the new process loaded the corrected hash, but the resumed task still received no node_repl or Chrome tool.
• A separately launched diagnostic browser runtime reports Browser is not available: chrome.

This points to Codex task tool routing/registration or extension-binding failure rather than Chrome permissions, extension enablement, or native-host manifest installation.

Codex feedback was recorded without uploading logs. Feedback thread ID: 01a03d37-63ec-7931-ae67-fee43bef4144.

[sternbj]

Follow-up verification on 2026-08-26 shows a split result after the local hash correction and full ChatGPT desktop restart.

Read-only test in a newly forked UI task:

• The bundled Chrome control skill is present and can be read.
• mcp__node_repl__js is not exposed to the task.
• No other node_repl tools are exposed.
• No Chrome-named control tools are exposed.
• No tool-discovery capability is available to load node_repl/js on demand.
• Therefore the Chrome browser binding cannot be initialized and even the open-tab list cannot be read through the required plugin interface.
• No navigation, clicks, typing, page reads, or other browser mutations were attempted.

Exact tool-presence result:

{
  "node_repl_js": [],
  "node_repl_any": [],
  "tool_search_tools": [],
  "chrome_named_tools": []
}

However, a separately launched fresh Codex process did expose mcp__node_repl__js, connected successfully to the Chrome extension, distinguished the connected Chrome profiles, and read the open tabs of the intended profile without navigation or modification.

The local repair therefore works for genuinely new Codex processes, while tasks forked from the affected app task can still inherit or retain the missing browser-tool binding. This appears to be a task/fork tool-manifest refresh issue rather than a continuing system-wide Chrome-extension failure.

[momo0328]

Additional deterministic reproduction from macOS on 2026-08-26:

Environment:

• ChatGPT desktop: 26.818.61809 (build 7019)
• Google Chrome: 151.0.7922.174
• ChatGPT Chrome extension: 1.2.27268.51612_0
• macOS on Apple Silicon
• Native-host protocol: v2

Isolation results:

• All packaged checks pass: Chrome running; extension installed, registered, and enabled; native-host manifest correct.
• A direct native-host handshake succeeds. The hello response advertises manifest schema 2 and native-host protocol 2.
• A direct ensure_codex_app_server request selects runtime 26.818.61809 and returns a populated runtimeConfig, including valid browserClientPath, browserServicePath, codexCliPath, nodePath, and nodeReplPath.
• A separate ChatGPT desktop task can use that same browser client to connect to Chrome and fill a field on the public https://httpbin.org/forms/post test page; the field update completed and was verified.
• After restarting the extension service worker, a genuinely new Chrome side-panel conversation on the same public page still receives only page-reading context. It reports that the native host did not provide a browser-client path, exposes no interactive Chrome-control interface, and leaves the test field unchanged.
• Global TUN proxying is enabled and the relevant upstream is reachable, so this is not explained by the earlier network path.

This narrows the regression to the handoff between the successful native-host ensure_codex_app_server response and side-panel task creation/capability routing: runtimeConfig.browserClientPath is present at the host boundary but is absent from the new sidebar task. The “native host is outdated” message is therefore misleading for this reproduction.

Codex feedback was also submitted previously. Feedback thread ID: 01a0310e-a6f1-7670-9896-e42e3841a450.

No private page data, credentials, cookies, account identifiers, screenshots, or local usernames are included.

[sandipb]

can you see if this workaround works: #39972 (comment)

[sternbj]

Confirmed — this workaround works on my setup. In a fresh Chrome side-panel chat, the explicit instruction loaded the Chrome integration, selected the correct Chrome profile, clicked a GitHub link, and navigated back successfully. This appears to be a skill-routing/profile-selection issue rather than an outdated native host. Thank you!