Chrome Browser Use: claimed signed-in tab consistently times out when reading DOM
Open 💬 3 comments Opened Jul 31, 2026 by GaryJinXD
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
Summary
In the Codex desktop app on macOS, the Chrome extension can detect and claim an already-open, signed-in third-party web-app tab, but every attempt to read the page content times out after about 30 seconds and resets the browser-use JS kernel.
Expected behavior
After claiming an existing Chrome tab, a read-only DOM snapshot or visible-DOM query should return the rendered page content, or return a specific actionable error.
Actual behavior
- Chrome extension is shown as Connected in Settings → Computer Use → Google Chrome.
- The target tab is discoverable and can be claimed successfully.
tab.playwright.domSnapshot()hangs until the JS execution timeout (~30 seconds), then reports that the kernel was reset.- After reinitializing,
tab.dom_cua.get_visible_dom()reproduces the same timeout and kernel reset.
Reproduction
- In Codex desktop app on macOS, connect the Chrome extension.
- Open and sign in to an arbitrary third-party web application in Chrome.
- Start a new Codex task and request a read-only inspection of the current page.
- The extension can enumerate and claim the tab, but DOM read requests time out.
Troubleshooting already completed
- Chrome extension was reinstalled.
- Codex desktop app and Chrome were restarted.
- A new Codex task was created.
- In Settings → Computer Use → Google Chrome, there are no site-specific permissions configured; default approval is “Always ask”.
Earlier in the session the browser tool returned an enterprise network policy blocks it error for the same tab. After the reinstall/restart that error no longer appeared; the content-read timeout above is now the consistent failure.
Privacy
This report intentionally omits the website URL, page content, account details, and business data.
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I can reproduce the same failure family on Windows (Spanish locale) with the current Chrome extension route. This reproduction is useful because the failure is page-specific: a neutral page works, while a public Spanish government page hangs on normal DOM/locator operations.
Environment
26.727.6591.026.727.513511.2.27236.6274Profile 2Verified installation state
latestplugin junction resolves to the current plugin version.Control test that succeeds
On
https://example.com/:tab.playwright.domSnapshot(): ~227 msReproduction that fails
On the public page:
https://sede.mjusticia.gob.es/es/tramites/certificado-nacimientoThe following operations work:
tab.playwright.evaluate()that reads counts and a limited list of controls: ~0.7 sThe following operations hang until the outer 15–30 s timeout and then reset the JS kernel:
tab.playwright.domSnapshot()tab.dom_cua.get_visible_dom()locator(...).count(),isVisible(), andinnerText()claimTab()/ capability reads on subsequent SERECI/Cl@ve tabsAfter a timeout, the page remains open in Chrome, but the Browser Use JavaScript kernel is reset. Retrying can repeat the same behavior and, on an authenticated government flow, the web session expires before the task can be completed.
Expected behavior
Normal DOM and locator operations should either return promptly, as they do on
example.com, or fail with a bounded, actionable error that identifies the failing bridge layer. They should not remain pending until the entire JS kernel is reset.Additional diagnostic note
The bundled native-host diagnostic also has a separate locale-dependent false negative on Spanish Windows: it searches the output of
reg query /vefor the literal English label(Default), while Spanish Windows prints(Predeterminado). The registry key itself is valid. This localization defect is already documented in #21741, so I am not duplicating that report here.No government form was submitted during this reproduction.
I can reproduce the same failure family on a current macOS build. In this case, the Chrome extension could enumerate tabs and locate an already-open, authenticated third-party admin page, but the operations needed to actually inspect or interact with that page repeatedly timed out.
Environment
Observed Chrome behavior
The shallow control path remained healthy:
The deeper control path consistently failed:
playwright.domSnapshot(): timed out after about 30.0 sdom_cua.get_visible_dom(): timed out after about 60.1 sBecause the paste/write result could not be observed, the assistant could not safely retry or click Save. The user had to finish the authenticated operation manually. This is particularly difficult in real administrative workflows: the browser appears connected and the correct signed-in tab is visible, but reliability disappears exactly when a stateful action must be verified.
In-app Browser control comparison
We then repeated the workflow through Codex's in-app Browser, using its separate browser profile and signing in there directly.
The first in-app Browser navigation still took about 37.7 s, and the first visible-DOM read took about 30.0 s while the logs showed Statsig
ab.chatgpt.cominitialization/registration timeouts. That appears related to the shared ambient-network delay tracked in #33713.However, after that initial delay, the same in-app Browser session became consistently responsive:
This control comparison makes the target site itself an unlikely primary cause. It also suggests that the shared Statsig/proxy delay and the Chrome-specific failure are overlapping but distinct: the in-app Browser recovered after initialization, while Chrome tab discovery continued to work but DOM, clipboard, and input operations did not.
Request
Could the Chrome path expose a privacy-safe diagnostic showing the state of each bridge layer—for example: native host connected, extension service worker alive, tab ownership/claim state, CDP attachment state, command acknowledgement, and the reason for any bridge reset? A supported “release stale claim / reconnect this tab” action would also be extremely helpful.
Most importantly, these operations should either complete promptly or fail with a bounded, actionable error. A silent 15–60 second hang leaves the user and the assistant unable to distinguish “not executed” from “executed but acknowledgement was lost,” which makes safe automation impossible.
We would be very grateful for a fix. The in-app Browser is a workable fallback when a separate login is acceptable, but it cannot fully replace the Chrome extension for workflows that depend on an existing authenticated Chrome profile.