Why does chrome-devtools-mcp make Chrome steal window focus on macOS with --autoConnect?
On macOS, running chrome-devtools-mcp with --autoConnect brings Chrome to the foreground on almost every tool call, including read-only ones like list_pages and take_screenshot. This pulls focus away from the terminal or IDE where the coding agent runs. The reporter used chrome-devtools-mcp 0.20.3 with Claude Code on macOS Sonoma.
Originally asked on GitHub: https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/1254
5 answers
The issue is marked closed (COMPLETED), but the thread shows no code change, maintainer explanation, or confirmed fix, so the problem should be treated as open.
What the thread reports:
- It started around Chrome 146, after a macOS auto-update in late March 2026. A collaborator could not reproduce it on Chrome 147 with macOS Sequoia and asked for a screencast.
- One reporter saw it more often when the iTerm2 terminal was in a different macOS Space from Chrome. The reporter said it "tends to" happen there, not that it happens only there.
- One reporter said focus moved to Chrome only while DevTools was open in some tab, and stayed in the background once all DevTools windows were closed. Others did not confirm this.
- One commenter's proxy logged no blocked Target.activateTarget or Page.bringToFront calls during focus-stealing list_pages and take_screenshot calls. This suggests the activation is not caused by those two CDP methods.
No workaround fully solves it. Setting bringToFront to false only helps select_page. Refocus hooks with osascript cause flicker, and keystrokes can land in Chrome during the switch.
Did this work for you?What a GitHub user tried on GitHub (Didn't work)
Used --autoConnect in Claude Code with bringToFront set to false on select_page. Moved Chrome to a separate macOS Space and added a PostToolUse osascript hook to refocus the terminal.
Source: https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/1254 (opens external site)
Did this work for you?What @nfarina tried on GitHub (Partly worked)
Closed all Chrome DevTools windows while keeping --autoConnect. The agent then controlled Chrome without stealing focus. Opening DevTools in any tab brought focus back.
Did this work for you?What @kiluazen tried on GitHub (Partly worked)
Used a Chrome MV3 extension with native messaging instead of CDP, relying on chrome.tabs.captureVisibleTab and chrome.tabs.query, which do not activate the window. This covers listing, screenshots, and DOM reads but not the full CDP surface.
Did this work for you?What @mimkorn tried on GitHub (Didn't work)
Placed the chrome-mcp-proxy CDP filter between the MCP server and Chrome to drop Target.activateTarget and Page.bringToFront. The proxy blocked 0 calls during focus-stealing list_pages and take_screenshot calls.
Did this work for you?
Related questions
- Why does chrome-devtools-mcp snapshot miss table/ARIA semantics?
- Why is --load-extension ignored by chrome-devtools-mcp?
- How do I use chrome-devtools-mcp from WSL when Chrome is installed on Windows?
- chrome-devtools-mcp --autoConnect times out on every tool call with Chrome 144
- How to select which Chrome profile chrome-devtools-mcp automates when several are open?