Background agent tab becomes active when navigation causes a beforeunload confirmation request (Chrome, macOS)

What happened

While I was using one Chrome tab, the agent was working in a background tab through the ChatGPT Chrome extension. Navigating that background tab caused that tab to become active, interrupting what I was doing.

A controlled local test reproduced this twice when the agent's tab had unsaved text and requested a beforeunload confirmation. The three corresponding control navigations without a confirmation request did not produce an observed switch.

Steps to reproduce

1. Keep another page active in Chrome.
2. Have the agent open a separate test tab through the Chrome extension.
3. In that test tab, enable an unsaved-changes guard and enter text through the browser tools.
4. Without saving, have the agent navigate that tab to another URL.
5. Observe Chrome switching from the tab you were using to the agent's tab.

The test page requests confirmation only when both the guard and unsaved state are enabled:

window.addEventListener('beforeunload', event => {
  if (guard.checked && dirty) {
    event.preventDefault();
    event.returnValue = '';
  }
});

In this fixture, typing sets dirty = true; the Save button clears it.

Controlled observations

State before navigation	Agent tab became active
Unsaved text, confirmation enabled	2/2
Text saved, confirmation enabled	0/2
Unsaved text, confirmation disabled	0/1

These are observations from a small number of runs, not an estimate of the overall occurrence rate.

Creating the test tab, refreshing, reading the DOM, taking a screenshot, and navigating without edits also did not produce an observed switch.

I visually confirmed both positive runs. As supporting evidence, the browser automation interface's browser.user.openTabs() returned an updated lastOpened timestamp for the existing test tab in both runs, approximately 9 ms and 15 ms after the page logged its confirmation request.

This was tool-exposed tab metadata. No raw Chrome tab-activation or CDP dialog event stream was captured.

All reproduction steps used the Chrome extension browser interface, with no native desktop control or explicit request to activate the agent's tab.

Expected behavior

Background browser work should preserve the user's active tab. If handling an unsaved-changes confirmation requires attention, the agent should make that explicit before interrupting the user.

Why this matters

Unexpected tab switching makes it difficult to use Chrome normally while an agent works in the background. Editing and navigating between pages are routine tasks, so this behavior can repeatedly interrupt the user's work.

Scope

This establishes a reproducible trigger in a local test page. It does not establish whether Chrome's dialog behavior or the automation client's dialog handling causes the activation.

An earlier occurrence during Notion use prompted this investigation, but whether it followed the same path remains unverified.

Environment

• macOS 26.6
• Chrome 152.0.7977.76
• Desktop app: 26.901.51231, build 8109 (com.openai.codex)
• ChatGPT Chrome extension: 1.26.901.11451

Start by tracing the Chrome extension browser interface through background-tab navigation and beforeunload confirmation handling, reproducing the supplied local test case on macOS. Compare navigations with and without an unsaved-changes confirmation, then verify that background work preserves the user's active tab or makes required attention explicit.