Allow passive MCP inspection without stealing foreground window focus

[samiralibabic]

Is your feature request related to a problem? Please describe.

I use chrome-devtools-mcp with a visible Chrome instance as part of a local side-agent workflow. The agent runs in opencode and uses CDP/MCP to inspect and test its work in Chrome while I continue using the same machine for other tasks, such as writing an email, working in Safari, using an IDE, or doing something else on another screen.

In this workflow, passive MCP activity such as inspecting or snapshotting pages can cause Chrome to become the active foreground window. That interrupts whatever I am doing manually. For example, I may be typing in another app, the agent uses MCP to inspect its Chrome page, Chrome becomes active, and my next keystrokes go into Chrome’s address bar or into whichever page element currently has focus.

This makes it difficult to let an agent work “on the side” using a visible browser, because ordinary inspection actions can interfere with the user’s active desktop session.

Describe the solution you'd like

Add an option to disable focused-page emulation or other foreground-focus side effects for passive page snapshot/inspection behavior, while keeping the existing default behavior unchanged.

Explicit focus-changing actions should still be possible. If the MCP client intentionally needs to bring Chrome or a page to the front, that should remain available. The issue is passive/background inspection causing Chrome to become active when the user did not ask for that.

This would preserve the current behavior for users who rely on focused-page emulation, while allowing users running visible browser agents on their own workstation to prevent the agent from interrupting their manual work.

Describe alternatives you've considered

• Running Chrome headless avoids stealing desktop focus, but removes the ability to visually monitor the browser while the agent works.
• Running the agent/browser on a separate machine or separate user session avoids the issue, but adds unnecessary operational overhead for a local workflow.
• Avoiding the machine while the agent works defeats the purpose of a side-agent workflow.
• Telling the agent not to bring Chrome to the front helps only for explicit foreground actions. It does not address passive inspection/snapshot behavior that can still make Chrome active.

Additional context

Related PR: #2271

This request is based on a real local workflow where an agent uses Chrome through MCP while the user continues working on the same machine. The requested behavior is an opt-out for passive inspection/snapshot focus side effects, not removal of explicit page activation.

[OrKoN]

Thanks for the FR. Emulating the focused page should not generally steal the window focus. E.g., if I run npx @modelcontextprotocol/inspector npx chrome-devtools-mcp@latest and call 'new_page(background=true)orlist_pages`, the windows focus would not changed after the initial browser startup. Which tool calls do you observe that are stealing the window focus? cc @zyzyzyryxy

[samiralibabic]

Thanks for the FR. Emulating the focused page should not generally steal the window focus. E.g., if I run npx @modelcontextprotocol/inspector npx chrome-devtools-mcp@latest and call 'new_page(background=true)orlist_pages`, the windows focus would not changed after the initial browser startup. Which tool calls do you observe that are stealing the window focus? cc @zyzyzyryxy

I rechecked the OpenCode transcript and the code path.

The passive focus issue showed up around read-only/passive calls like list_console_messages and evaluate_script. Those handlers do not call bringToFront() directly, but every tool call can go through MCP context/page discovery, and that path calls createPagesSnapshot(), which was unconditionally calling page.emulateFocusedPage(true) for discovered pages.

After running my local build with --no-emulate-focused-pages, those passive calls no longer appeared to steal focus.

The only remaining concrete activation I captured was select_page with bringToFront=true. I agree that one is explicit activation and expected; this PR is not intended to suppress it.

[OrKoN]

@samiralibabic thanks for details! which platform are you seeing this on, and that chrome-devtools-mcp and Chrome versions do you run?