Browser Use IAB should classify recoverable CDP command timeouts instead of cleanup-and-rethrow

Open 💬 3 comments Opened May 7, 2026 by scottfalconer
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

26.429.61741

What subscription do you have?

ChatGPT Pro

What platform is your computer?

macOS / Darwin arm64

  • OS kernel: Darwin 24.5.0 RELEASE_ARM64_T6000 arm64
  • Codex app: CFBundleShortVersionString=26.429.61741, CFBundleVersion=2429
  • Browser Use plugin: browser-use 0.1.0-alpha1
  • Browser Use backend: iab
  • Session meta CLI version: 0.128.0-alpha.1
  • Current shell CLI version: codex-cli 0.128.0

What issue are you seeing?

Browser Use IAB surfaced an intermittent timeout from a safe visual-read command:

Timed out running CDP command "Page.captureScreenshot" for tab 1

The observed user-facing failure happened during:

await display(await tab.playwright.screenshot({ fullPage: false }));

The failure occurred before display(...) received image bytes. The raw tool result named CDP Page.captureScreenshot, with elapsed wall time around 20.0s even though the surrounding Node REPL tool call had timeout_ms: 30000.

This was not a deterministic page-rendering failure:

  • Immediately before the screenshot call, title/URL/console inspection worked.
  • Immediately after the screenshot timeout, tab.playwright.domSnapshot() succeeded on the same Browser Use tab.
  • Later recovery testing in a fresh Browser Use session succeeded for the same URL/tab shape:
  • same tab screenshot: ~87 ms
  • same tab after reload: ~60 ms
  • fresh Browser Use tab: ~60 ms
  • repeated screenshot calls later succeeded around ~40-44 ms
  • No browser console warnings/errors were observed for the page.

So the narrower symptom is "screenshot timed out," but the more fundamental issue appears to be that Browser Use IAB treats CDP command timeouts as generic cleanup-and-rethrow failures rather than classifying whether the command is recoverable or safe to retry.

What steps can reproduce the bug?

I do not currently have a deterministic repro. The original failure was captured in a real Codex Desktop Browser Use session while the in-app browser had a local page open:

http://127.0.0.1:8776/live-map.html?outing=1-2

Exact failing command from the session log:

await display(await tab.playwright.screenshot({ fullPage: false }));

Exact error returned by the Browser Use call:

Timed out running CDP command "Page.captureScreenshot" for tab 1

The command duration in the raw log was approximately 20.026 seconds.

What is the expected behavior?

Browser Use IAB should not treat every CDP command timeout the same way.

For safe/idempotent visual-read commands such as Page.captureScreenshot and likely nearby layout/DOM read commands, IAB should be able to classify the timeout as recoverable, detach/reattach if needed, and retry once or otherwise surface a structured recoverable error that guides the caller to retry.

It should not blindly retry side-effecting commands such as input, click, navigation, close, or reload commands where duplication could be harmful.

What is the actual behavior?

The observed screenshot call failed with a plain timeout error. The agent did not receive screenshot bytes, and the failure appeared terminal even though the same tab continued to respond to other Browser Use commands immediately afterward.

Code inspection of the bundled Desktop/IAB path suggests this is expected from the current implementation:

  • The Browser Use JS screenshot helper calls Page.getLayoutMetrics, then Page.captureScreenshot.
  • cua_get_visible_screenshot also calls Page.captureScreenshot directly.
  • The Codex Desktop IAB backend wraps ordinary webContents.debugger.sendCommand(...) calls with a default 20s timeout.
  • On any error whose message starts with Timed out, the IAB backend calls debugger cleanup with reason cdp-timeout, then rethrows the original timeout.
  • There does not appear to be retry/backoff or method-aware recoverability classification around this path.

The same code area already has command-specific handling for other cases:

  • Page.reload bypasses raw CDP and uses Electron reload APIs.
  • Input.* commands are translated to JavaScript because input handling has IAB-specific focus/safety constraints.
  • Page.close has explicit cleanup behavior.
  • initial page load and navigation-history lookup have separate timeout messages/paths.

That suggests the missing abstraction is not screenshot-specific; it is a method-aware CDP timeout policy for IAB.

Additional information

This is intentionally filed as an evidence-supported intermittent Browser Use/IAB robustness issue, not as a deterministic page bug.

Potential fix direction:

  • Introduce a small CDP timeout classification layer in the IAB backend.
  • Mark safe read/capture commands as retryable after cleanup/reattach, with a low retry count such as one attempt.
  • Keep input/navigation/close/reload commands non-retryable unless they have explicit command-specific recovery semantics.
  • Return structured error metadata when a timeout was cleaned up and the tab/browser may still be usable.

This would make the observed Page.captureScreenshot failure recover better while avoiding unsafe duplicate interactions.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 3 months ago

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

  • #21452

Powered by Codex Action

scottfalconer · 3 months ago

Thanks. #21452 is related, but I do not think this is a strict duplicate.

The overlap is that both reports can involve Page.captureScreenshot timing out while the Browser Use tab is otherwise still usable. The differences are the important part:

  • #21452 is Windows-specific and primarily about the screenshot surface invariant: target-tab screenshots can time out, and an attempted fromSurface: false workaround can capture the visible Codex/chat window instead of the controlled Browser Use tab.
  • This issue was observed on macOS with the normal IAB path. There was no wrong-window fallback and no fromSurface: false workaround involved.
  • In this issue, Browser Use was already connected to IAB, and the same tab remained responsive before and after the timeout: title/URL/console inspection worked before it, and tab.playwright.domSnapshot() worked immediately after it.
  • The code-level concern here is broader than screenshots: ordinary IAB webContents.debugger.sendCommand(...) calls are wrapped in a 20s timeout, and any Timed out... error triggers debugger cleanup with reason cdp-timeout and then rethrows. There does not appear to be method-aware classification for safe/retryable CDP reads versus side-effecting commands.

So #21452 is useful sibling evidence for one screenshot manifestation, but this issue is tracking the more general IAB CDP-timeout recovery policy. If maintainers prefer to consolidate, I would suggest keeping this broader invariant attached to the merged issue rather than treating it as only the Windows target-surface/fallback bug.

Marabun · 2 months ago

Additional macOS evidence for the same IAB robustness class, with a second failure mode after the CDP timeout.

Environment:

  • Codex.app: 26.527.31326 (build 3390)
  • codex-cli: 0.135.0
  • macOS: 26.5 (25F71)
  • Browser backend: IAB

Observed sequence:

  1. Browser Use could control a local in-app browser page and perform DOM-based checks.
  2. A screenshot request failed with:
Timed out running CDP command "Page.captureScreenshot"
  1. After that timeout, a later attempt to use the current/visible in-app Browser tab failed at the attach/session layer:
Timed out waiting for the Browser webview to attach for this browser-use page
  1. The user-visible in-app browser ended up on about:blank.
  2. Opening a fresh Browser Use tab still worked for the same kind of local test page, so the local page itself was not the root cause.

This looks related to the existing recoverable CDP-timeout discussion, but the follow-on symptom is broader than screenshot capture: after the screenshot timeout, IAB can also fail to attach/get tabs for the current webview. A useful fix would likely include both method-aware recovery for safe CDP read commands and robust reattach/rebind behavior when the current IAB webview session gets into this state.

All local paths, project names, URLs, and session identifiers are intentionally omitted here.