[Bug] Chrome MCP server causes tab crash on copy-paste operations

Chrome browser process hangs (right-click dead, external paste hangs) while a CDP/automation client is attached to the primary browsing profile

Summary

On Linux/X11, when an automation client attaches to the user's everyday Chrome
over the DevTools Protocol (via the claude-in-chrome extension integration and/or the
chrome-devtools-mcp server), Chrome's browser process intermittently wedges:

• Right-click context menus stop appearing.
• Pasting an externally-owned X selection hangs the browser and a child process is

killed by the hang watchdog:
FATAL:content/child/child_thread_impl.cc:377] Crashing because hung.

• Affects both X11 selections — CLIPBOARD (Ctrl+V) and PRIMARY (middle-click).
• Internal Chrome→Chrome paste (served from Chrome's own cache) is unaffected.
• Normal browsing/rendering is otherwise fine.

Impact

The everyday browser becomes unusable for paste and context menus until Chrome (and
sometimes the whole X session) is restarted. The user is unaware automation is attached,
so the failure looks like a random Chrome/X bug.

Environment

| | |
|---|---|
| Chrome | 150.0.7871.114 (Google .deb, /usr/bin/google-chrome) |
| OS / kernel | Linux 6.17.0-35-generic |
| Session | X11 (XDG_SESSION_TYPE=x11), WM: i3 |
| GPU | NVIDIA RTX 4070 Ti, driver 570.211.01, via ANGLE/OpenGL (GPU process crash count: 0) |
| Displays | 3 external monitors, one rotated 90° |
| Automation | claude-in-chrome (extension, drives existing session) + chrome-devtools-mcp (CDP); MCP observed connecting/disconnecting repeatedly |

Reproduction

1. From a clean X session, have the claude-in-chrome / chrome-devtools-mcp automation

attached to (or discoverable by) the primary Chrome profile.
chrome://inspect had "Discover network targets" enabled with a live remote target.

1. Copy plain text from another app (e.g. a terminal).
2. Paste into a Chrome field (address bar or page input) with Ctrl+V.
3. Works for ~3 pastes, then a paste hangs; ~5s later the tab/child dies

("Crashing because hung"). Right-click also stops producing a context menu.

Key evidence isolating the cause

• Content ruled out — clipboard held clean ASCII ("In-store network and internet

connectivity"), no HTML flavor, no control chars (xclip -o -t TARGETS = TARGETS,
UTF8_STRING only).

• Selection owner ruled out — reproduced with terminal, xclip, and copyq as owner;

copyq clipboard reads the value back instantly.

• X server / driver ruled out — Firefox (independent clipboard/input impl) is

rock-solid pasting the same selection; other GUI apps paste it instantly.

• GPU ruled out — chrome://gpu shows HW accel active, GPU process crash count 0;

--disable-gpu did not fix it (first paste worked, next hung).

• Portal ruled out — dbus-monitor shows no org.freedesktop.portal.FileTransfer

call during paste; restarting xdg-desktop-portal had no effect.

• Not content/renderer — the omnibox (browser-process UI) also hangs, so the stall is

the browser process's handling of the X selection round-trip / nested UI loop, not a
renderer.

• Cumulative + self-healing — works a few times then wedges; "heals" on its own or on

restart, matching a CDP client attaching/detaching.

• Fixed by removing automation — a clean profile launched with

google-chrome --user-data-dir=/tmp/chrome-clean --disable-extensions works normally
(right-click + paste). Incognito did not help (the integration has incognito access
and attaches browser-wide via the debugger API, so Incognito doesn't escape it).

Likely mechanism

Right-click context menus and external-selection pastes both require Chrome's browser UI
thread to run a nested message loop and wait on X events (menu popup; SelectionNotify
reply). While a chrome.debugger / CDP session is attached to the browsing tabs, input
routing goes through the automation layer and these nested waits stop completing — so
menus never open and selection reads hang until the watchdog fires. Internal paste needs
no nested wait, so it survives.

Suggested fixes / mitigations

• Automation should never auto-attach to the user's primary browsing profile. Default

to a dedicated/isolated instance (as @playwright/mcp does by default), or require
explicit opt-in per session and detach cleanly when idle.

• Surface a clear, dismissible indicator when a CDP/debugger session is attached to

everyday tabs.

• Investigate why an attached CDP session breaks native context menus + blocks

CLIPBOARD/PRIMARY selection reads in the browser process on X11/Ozone.

Workarounds for users hitting this

• Use an isolated automation profile (--user-data-dir=…); never point automation at

your daily Chrome.

• chrome://inspect → uncheck "Discover network targets" and **"Discover USB

devices"**.

• Immediate relief: detach the automation client, or pkill -e chrome (occasionally a

full X-session restart).

• Firefox is unaffected as a fallback.

chrome-paste-hang-transcript.redacted.txt