Integrated browser: unattended JS dialogs (alert/confirm/prompt) queue up and freeze the desktop app

Summary

When an agent tests web code that calls alert() (or confirm() / prompt()) in the integrated browser of the Claude desktop app, the blocking modal dialogs queue up unattended. Over an agent session this can produce hundreds or thousands of queued dialogs, degrading the entire desktop app to a crawl until each one is manually dismissed.

Steps to reproduce

1. In the desktop app, have an agent build web code that intentionally uses JavaScript alert().
2. Let the agent iteratively test the code in the integrated browser.
3. Each test run fires alert(), producing a blocking modal dialog.
4. Because the user isn't actively watching, the dialogs queue behind one another.

Actual behavior

• Dialogs accumulate (hundreds/thousands) with a single visible alert waiting for a click and the rest queued behind it.
• The desktop app slows to an unusable crawl.
• Recovery required force-quitting and restarting the app, then instructing the agent not to test in the integrated browser.

Expected behavior

• The integrated browser should auto-dismiss or suppress JS dialogs (alert/confirm/prompt) during agent-driven testing, or
• Cap the number of dialogs that can queue, or
• Surface a "suppress further dialogs from this page" control.

Impact

Any agent workflow that tests code using native JS dialogs can unintentionally lock up the desktop app.

Environment

• OS: macOS 26.5.1 (build 25F80)
• Architecture: arm64 (Apple Silicon)
• Claude desktop app version: 1.22209.0
• Claude Code version: 2.1.201
• gh version: 2.83.1