You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
docs: Update README with WSL configuration details (#946)
Added workarounds for using chrome-devtools-mcp in WSL.
Drive-by: moved known issues from readme to troubleshooting.
Drive-by: updated skill to link to troubleshooting.
Drive-by: rephrased for clarity.
Copy file name to clipboardExpand all lines: docs/troubleshooting.md
+33-10Lines changed: 33 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -55,23 +55,46 @@ This indicates that the browser could not be started. Make sure that no Chrome
55
55
instances are running or close them. Make sure you have the latest stable Chrome
56
56
installed and that [your system is able to run Chrome](https://support.google.com/chrome/a/answer/7100626?hl=en).
57
57
58
-
### Chrome crashes on macOS when opening Web Bluetooth
58
+
### Chrome crashes on macOS when using Web Bluetooth
59
59
60
-
On macOS, Chrome launched by an MCP host app may crash with a macOS privacy
61
-
permission violation (TCC, "Transparency, Consent, and Control") when a native
62
-
Bluetooth chooser opens.
60
+
On macOS, Chrome launched by an MCP client application (such as Claude Desktop) may crash when a Web Bluetooth prompt appears. This is caused by a macOS privacy permission violation (TCC).
63
61
64
-
Grant Bluetooth permission to the MCP host app in
65
-
`System Settings > Privacy & Security > Bluetooth`, then restart the MCP host
66
-
app and Chrome MCP session.
62
+
To resolve this, grant Bluetooth permission to the MCP client application in `System Settings > Privacy & Security > Bluetooth`. After granting permission, restart the client application and start a new MCP session.
67
63
68
64
### Remote debugging between virtual machine (VM) and host fails
69
65
70
-
When connecting DevTools inside a VM to Chrome running on the host, any domain is rejected by Chrome because of host header validation. Tunneling the port over SSH bypasses this restriction. In the VM, run:
66
+
When attempting to connect to Chrome running on a host machine from within a virtual machine (VM), Chrome may reject the connection due to 'Host' header validation. You can bypass this restriction by creating an SSH tunnel from the VM to the host. In the VM, run:
Point the MCP connection inside the VM to `http://127.0.0.1:9222` and DevTools
77
-
will reach the host browser without triggering the Host validation.
72
+
Point the MCP connection inside the VM to `http://127.0.0.1:9222`. This allows DevTools to reach the host browser without triggering the Host validation error.
73
+
74
+
### Operating system sandboxes
75
+
76
+
Some MCP clients allow sandboxing the MCP server using macOS Seatbelt or Linux
77
+
containers. If sandboxes are enabled, `chrome-devtools-mcp` is not able to start
78
+
Chrome that requires permissions to create its own sandboxes. As a workaround,
79
+
either disable sandboxing for `chrome-devtools-mcp` in your MCP client or use
80
+
`--browser-url` to connect to a Chrome instance that you start manually outside
81
+
of the MCP client sandbox.
82
+
83
+
### WSL
84
+
85
+
By default, `chrome-devtools-mcp` in WSL requires Chrome to be installed within the Linux environment. While it normally attempts to launch Chrome on the Windows side, this currently fails due to a [known WSL issue](https://github.com/microsoft/WSL/issues/14201). Ensure you are using a [Linux distribution compatible with Chrome](https://support.google.com/chrome/a/answer/7100626).
If there are errors launching `chrome-devtools-mcp` or Chrome, refer to https://github.com/ChromeDevTools/chrome-devtools-mcp/blob/main/docs/troubleshooting.md.
0 commit comments