Chrome browser-use hangs on JavaScript confirm() dialogs; handle confirm like alert/beforeunload or expose dialog handling

Open 💬 1 comment Opened May 22, 2026 by NAEL592

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.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗