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

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

• #39972
• #40077

Powered by Codex Action

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.

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.

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.

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.

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.

can you see if this workaround works: https://github.com/openai/codex/issues/39972#issuecomment-5445873395

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!