codex - 💡(How to fix) Fix Chrome browser-use hangs on JavaScript confirm() dialogs; handle confirm like alert/beforeunload or expose dialog handling

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Root Cause

Many real web apps use native confirm() for low-level remove/delete actions. Browser-use can already click the initiating control and can handle some native dialogs, but this missing confirm case makes otherwise normal workflows fail mid-task.

Fix Action

Fix / Workaround

In the bundled scripts/browser-client.mjs, the JavaScript dialog handler handles Page.javascriptDialogOpening but only accepts alert and beforeunload. A minimal local patch that fixed the hang was to include confirm in that accepted set:

Code Example

if (confirm("Remove this item?")) {
  return $.post(removeUrl, withCsrf());
}

---

- if (n !== "alert" && n !== "beforeunload" || typeof o !== "number") return;
+ if (n !== "alert" && n !== "beforeunload" && n !== "confirm" || typeof o !== "number") return;
RAW_BUFFERClick to expand / collapse

What version of Codex / plugin are you using?

  • Codex Desktop: 26.519.x on Windows
  • Chrome plugin: chrome@openai-bundled / 26.519.31651
  • Codex Chrome Extension ID: hehggadaopoacecdllhhajmbjkdcmajg
  • Browser backend: Chrome extension backend

What issue are you seeing?

When a page opens a native JavaScript confirm() dialog during a Chrome browser-use action, the automation call hangs. In my case, itch.io uses confirm("Remove this game from the collection?") before posting a collection remove action. Clicking the page's Remove... link through the Chrome plugin opened the native confirm dialog, and subsequent browser-use calls timed out waiting on Chrome input / CDP interaction.

This is different from alert and beforeunload, which the bundled browser client already auto-handles. The current dialog handler appears to accept only those two dialog types, leaving confirm unresolved.

Reproduction

  1. Use chrome@openai-bundled with an authenticated Chrome session.
  2. Navigate to a page that triggers a native confirm() from a normal click handler. Example class of flow: a web app's delete/remove button implemented as:
if (confirm("Remove this item?")) {
  return $.post(removeUrl, withCsrf());
}
  1. Click the triggering element via browser-use / Chrome plugin.
  2. Observe the tool call hang or time out because the confirm dialog remains open.

Expected behavior

The browser runtime should not hang on native confirm() dialogs. Either:

  • handle confirm the same way as alert / beforeunload when the dialog is opened as a direct result of an approved browser-use action, or
  • expose a supported dialog handling primitive so agents can accept/dismiss the dialog deliberately.

Local diagnosis

In the bundled scripts/browser-client.mjs, the JavaScript dialog handler handles Page.javascriptDialogOpening but only accepts alert and beforeunload. A minimal local patch that fixed the hang was to include confirm in that accepted set:

- if (n !== "alert" && n !== "beforeunload" || typeof o !== "number") return;
+ if (n !== "alert" && n !== "beforeunload" && n !== "confirm" || typeof o !== "number") return;

After reloading the browser runtime with that change, the same itch.io remove flow completed successfully. I verified it by removing duplicate collection entries and then re-reading the collection pages; the duplicate check returned an empty list.

Safety note

Automatically accepting every confirm() globally may be broader than desired. A safer upstream implementation could limit auto-acceptance to dialogs that are opened during an already-approved click/action, or expose explicit dialog handling to the agent layer. The main bug is that unresolved confirm() dialogs currently leave Chrome browser-use stuck with no recovery path from the normal tool surface.

Why this matters

Many real web apps use native confirm() for low-level remove/delete actions. Browser-use can already click the initiating control and can handle some native dialogs, but this missing confirm case makes otherwise normal workflows fail mid-task.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

The browser runtime should not hang on native confirm() dialogs. Either:

  • handle confirm the same way as alert / beforeunload when the dialog is opened as a direct result of an approved browser-use action, or
  • expose a supported dialog handling primitive so agents can accept/dismiss the dialog deliberately.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING