Repository navigation
ChatGPT Chrome sidebar is read-only and falsely reports an outdated native host #40118
Description
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
- Install and enable the official ChatGPT Chrome extension.
- Confirm that the native host and extension are connected.
- Open an authenticated website such as Meta Business Suite.
- Open the ChatGPT Chrome sidebar.
- Ask it to click a visible link or button.
- Observe that it reads the page correctly but refuses to interact, claiming the native component is outdated.
- 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.
Activity
github-actions commentedon Aug 22, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
sternbj commentedon Aug 24, 2026
Reproduced again on macOS in the ChatGPT Chrome side panel on 2026-08-24.
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 commentedon Aug 24, 2026
Additional environment and retry details from another reproduction on 2026-08-24:
No private page content, account identifiers, credentials, screenshots, or private URLs are included.
sternbj commentedon Aug 26, 2026
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:
Additional isolation results:
node_replor Chrome tool at all.node_replMCP executable starts successfully when tested directly.tools/listresponse includesjs,js_add_node_module_dir, andjs_reset, so the local server itself is healthy.2158647076eed887c7591cca0957da78747ab9155819d64409d6b895e84ed99b.node_replor Chrome tool.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 commentedon Aug 26, 2026
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:
mcp__node_repl__jsis not exposed to the task.node_repltools are exposed.node_repl/json demand.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 commentedon Aug 26, 2026
Additional deterministic reproduction from macOS on 2026-08-26:
Environment:
Isolation results:
ensure_codex_app_serverrequest selects runtime 26.818.61809 and returns a populatedruntimeConfig, including validbrowserClientPath,browserServicePath,codexCliPath,nodePath, andnodeReplPath.https://httpbin.org/forms/posttest page; the field update completed and was verified.This narrows the regression to the handoff between the successful native-host
ensure_codex_app_serverresponse and side-panel task creation/capability routing:runtimeConfig.browserClientPathis 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 commentedon Aug 27, 2026
can you see if this workaround works: #39972 (comment)
sternbj commentedon Aug 28, 2026
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!
majidasli commentedon Aug 29, 2026
Confirming the same issue on Windows with a newer Codex App build.
Environment:
The Chrome extension and native-host diagnostics all pass: the extension is installed and enabled in the selected profile, the manifest and registry path match, and all expected extension origins are allowed.
A sidebar conversation can consistently read authenticated WordPress, Hostinger, and GitHub pages, but it receives no interactive click, type, or navigation controls and reports the native host as unavailable or outdated. In a separate Codex desktop task, the same authenticated WordPress tab was successfully claimed, Dashboard was clicked, and text was typed and cleared in Quick Draft without saving. This confirms that the failure is specific to the capability exposed to sidebar conversations rather than the extension installation or native-host transport.
Originally reported as #41458; I am closing that issue as a duplicate of this one.
oneplus7profan-jpg commentedon Aug 31, 2026
Additional Windows reproduction with a useful isolation result (2026-09-01):
Environment:
26.825.41651OpenAI.Codex 26.825.5331.0152.0.7977.651.2.27268.51612Observed behavior in the Chrome side panel:
click,type, andnavigateare unavailable.Important isolation result:
This seems to match the split state described in this issue more closely than a genuinely outdated/broken native host. The “native host is out of date” message is therefore likely misleading in this reproduction.