macOS: Chrome steals window focus on every CDP command

[pavnaumenko-fl]

Description

When using chrome-devtools-mcp on macOS, Chrome steals window focus from the active application (terminal, VS Code, etc.) on virtually every MCP tool call — including read-only operations like take_screenshot, list_pages, and select_page (with bringToFront omitted/false).

This makes the MCP very disruptive to use in AI coding agents (Claude Code, Cursor, etc.) where the user is working in their IDE/terminal while the agent interacts with Chrome in the background.

Environment

• OS: macOS (Sonoma)
• chrome-devtools-mcp: 0.20.3
• Connection mode: --autoConnect
• MCP client: Claude Code (CLI)

Steps to reproduce

1. Open Chrome with remote debugging enabled
2. Start chrome-devtools-mcp with --autoConnect
3. Focus a different application (e.g., VS Code terminal)
4. Call any MCP tool (e.g., take_screenshot, select_page, list_pages)
5. Observe: Chrome window activates and steals focus from the current application

What I expected

Read-only CDP operations (screenshots, snapshots, page listing) should not activate the Chrome window. Only explicit user-facing actions (like bringToFront: true) should change window focus.

Workarounds attempted (none worked)

• bringToFront: false on select_page — helps for that specific call, but other tools still steal focus
• macOS Spaces — moving Chrome to a separate virtual desktop; Chrome still gets activated
• PostToolUse hook with osascript to refocus the terminal — causes visible blinking (Chrome activates then terminal activates), worse UX than the original problem
• Opening a new Chrome window in a separate Space — same result, Chrome as an app gets activated

Root cause

This appears to be a Chromium-level issue where CDP WebSocket communication triggers macOS window activation. Related Chromium bugs (open for 10+ years):

• chromium#223828 — Chrome window steals focus when driven by chromedriver
• chromium#40770130 — Chrome window randomly steals focus
• chromium#40182355 — Chromium steals focus at launch on macOS

Possible solutions

• Add a --no-activate or --background server flag that suppresses window activation during CDP communication
• Use headless CDP session for read-only operations where possible
• Investigate which specific CDP commands trigger macOS NSApplication activate and avoid them for non-interactive tools
• Add background: true / focus: false parameters to Target.createTarget calls where applicable

[achiya-automation]

Focus stealing on macOS is exactly why I built Safari MCP. Every CDP command bringing Chrome to the foreground makes it unusable during active work.

Safari MCP solves this by targeting tabs by index via AppleScript — Safari never comes to the foreground. For native clicks, CGEvent targets specific window IDs without moving the cursor. Your active app stays focused.

https://github.com/achiya-automation/safari-mcp — 80 tools, MIT licensed.

[TwoToneBytes]

Chrome version correlation: This started with Chrome 146.0.7680.80, which auto-updated on macOS around March 23. The chrome-devtools-mcp source confirms bringToFront is only called explicitly in select_page when bringToFront: true, and evaluate_script has no focus-related calls. The regression is at the Chromium/CDP layer, not the MCP server.

The Chrome binary on my machine shows modification date of March 13, with the .app bundle updated March 23, consistent with the timeline of this issue appearing.

[OrKoN]

I am not able to reproduce on MacOS Sequoia Version 15.7.5 and Chrome 147.0.7727.24 (Official Build) (arm64). Could you please record a screencast?

[priyadarshy]

This just started happening to me today but it doesn't always happen. I think there might be something going on where it tends to happen when I'm running Claude in a iTerm2 window that's not in the same OS X space as my Chrome browser. Maybe that clue will help someone else reproduce? I'll keep an eye out and try and record next time it happens to me.