Start Canary when --autoConnect is used, but Canary isn't running.

[richardkmichael]

The --autoConnect feature is handy, since I do occasionally have Canary running when I'm debugging myself.

But, I don't always have it running before using the LLM, and so I'd like it to auto-start, and without asking me to "Accept remote debugging", for smoother workflow.

I wrote a small patch for this, but discovered it's an intentional design-decision to not auto-start.

If it's helpful for anyone, here's a fair amount of glue to make it happen.

.mcp.json

{
  "mcpServers": {
    "chrome-devtools": {
      "type": "stdio",
      "command": "npx",
      "args": [
        "chrome-devtools-mcp@latest",
        "--autoConnect",
        "--channel=canary",
        "--userDataDir=/path/to/.cache/chrome-devtools-mcp/chrome-profile-canary"
      ]
    }
  }
}

Chrome start script for the LLM: `chrome-canary.sh`

#!/bin/bash
#
# Chrome Canary launcher for chrome-devtools-mcp
# Usage: chrome-canary.sh --start | --stop
#
# PURPOSE:
#
# This script starts Chrome Canary in a way that allows the chrome-devtools-mcp server to connect
# via the DevTools Protocol without requiring the user to manually click "Allow" on a remote
# debugging permission dialog.
#
# WHY:
#
# Chrome 136+ introduced a security restriction: the --remote-debugging-port flag is blocked when
# using Chrome's default profile directory. This prevents malicious software from silently enabling
# remote debugging to steal cookies.
#
# The only way to use --remote-debugging-port is with a non-default --user-data-dir.  This script
# uses the same profile directory that chrome-devtools-mcp uses when it launches Chrome itself:
# ~/.cache/chrome-devtools-mcp/chrome-profile-canary
#
# HOW IT WORKS:
#
# 1. Chrome starts with --remote-debugging-port=0 (Chrome picks an available port)
# 2. Chrome writes the chosen port to DevToolsActivePort in the user-data-dir
# 3. The MCP server (configured with --userDataDir pointing to the same location)
#    reads DevToolsActivePort to find the port and connect
#
# MCP SERVER CONFIGURATION:
#
# --autoConnect assumes Canary has already been started, and searches for DevToolsActivePort in the
# user's default Canary profile.
#
# Therefore, the MCP server must be configured with --userDataDir pointing to the same directory
# used by this script, so it will find our DevToolsActivePort.
#
# Also, userDataDir must be absolute; implicit $HOME/ construction is only done when the MCP starts
# Chrome itself.
#
# Example .mcp.json:
#
#   {
#     "mcpServers": {
#       "chrome-devtools": {
#         "command": "npx",
#         "args": [
#           "chrome-devtools-mcp@latest",
#           "--autoConnect",
#           "--channel=canary",
#           "--userDataDir=/path/to/.cache/chrome-devtools-mcp/chrome-profile-canary"
#         ]
#       }
#     }
#   }
#
# CHROME FLAGS EXPLAINED:
#   --remote-debugging-port=0   Enable remote debugging; 0 = pick available port
#   --user-data-dir=<path>      Use non-default profile (required to enable remote debugging)
#   --profile-directory=Default Use the "Default" profile within user-data-dir
#   --no-default-browser-check  Suppress "make Chrome your default browser" prompt
#   --no-first-run              Suppress first-run welcome wizard
#   --disable-profile-picker    Suppress profile selection dialog
#   about:blank                 Open a blank page (ensures a page is available)
#
# NOTE: The MCP server doesn't support --profile-directory. When the MCP server
# launches Chrome itself, it may show a profile picker. This script avoids that
# by explicitly passing --profile-directory=Default.
#

CHROME_BIN="/Applications/Google Chrome Canary.app/Contents/MacOS/Google Chrome Canary"
LOG_FILE="${TMPDIR:-/tmp}/chrome-canary.log"
PID_FILE="${TMPDIR:-/tmp}/chrome-canary.pid"
USER_DATA_DIR="$HOME/.cache/chrome-devtools-mcp/chrome-profile-canary"

start_chrome() {
    "$CHROME_BIN" \
        --remote-debugging-port=0 \
        --user-data-dir="$USER_DATA_DIR" \
        --profile-directory=Default \
        --no-default-browser-check \
        --no-first-run \
        --disable-profile-picker \
        about:blank \
        > "$LOG_FILE" 2>&1 &

    CHROME_PID=$!
    echo "{\"canary_pid\": $CHROME_PID}" > "$PID_FILE"
    cat "$PID_FILE"
}

stop_chrome() {
    if [[ -f "$PID_FILE" ]]; then
        CHROME_PID=$(grep -o '"canary_pid": [0-9]*' "$PID_FILE" | grep -o '[0-9]*')
        if [[ -n "$CHROME_PID" ]]; then
            kill "$CHROME_PID" 2>/dev/null
            rm -f "$PID_FILE"
            echo "{\"stopped\": $CHROME_PID}"
        else
            echo "{\"error\": \"Could not parse PID from $PID_FILE\"}" >&2
            exit 1
        fi
    else
        echo "{\"error\": \"No PID file found at $PID_FILE\"}" >&2
        exit 1
    fi
}

case "$1" in
    --start)
        start_chrome
        ;;
    --stop)
        stop_chrome
        ;;
    *)
        echo "Usage: $0 --start | --stop" >&2
        exit 1
        ;;
esac

LLM instructions

# Handle chrome-devtools MCP server error

When any chrome-devtools tool returns this error:

```
Error: Could not connect to Chrome. Check if Chrome is running and remote debugging is enabled by going to chrome://inspect/#remote-debugging.
```

Start Chrome manually with: `./chrome-canary.sh --start`

Claude Code permissions (including the MCP)

{
  "permissions": {
    "allow": [
      "Bash(./chrome-canary.sh:*)",
      "mcp__chrome-devtools"
    ]
  },
  "enabledMcpjsonServers": [
    "chrome-devtools"
  ]
}

macOS osascript to compile for an app shortcut (Spotlight, etc.)

-- Canary Dev.applescript
-- Launches Chrome Canary with remote debugging enabled using a dedicated dev profile.
--
-- This profile is stored at ~/.cache/chrome-devtools-mcp/chrome-profile-canary,
-- which is the default location used by chrome-devtools-mcp when --channel=canary
-- is specified. This allows the MCP server to connect without additional config.
--
-- Compile with:
--   osacompile -o "Canary Dev.app" "Canary Dev.applescript"

set userHome to POSIX path of (path to home folder)
set userDataDir to userHome & ".cache/chrome-devtools-mcp/chrome-profile-canary"
set chromeBin to "/Applications/Google Chrome Canary.app/Contents/MacOS/Google Chrome Canary"

set chromeCmd to quoted form of chromeBin & " " & ¬
	"--remote-debugging-port=0 " & ¬
	"--user-data-dir=" & quoted form of userDataDir & " " & ¬
	"--profile-directory=Default " & ¬
	"--no-default-browser-check " & ¬
	"--no-first-run " & ¬
	"--disable-profile-picker " & ¬
	"about:blank " & ¬
	"&> /dev/null &"

do shell script chromeCmd

[sebastianbenz]

Thanks a lot for this! //cc @OrKoN

[OrKoN]

cc @natorion

[natorion]

I think an autostart would be fine.

It is a deliberate decision to only accept a remote connection on explicit user consent, so that's a no-go.

[PaulRBerg]

This workaround is useful, especially for a dedicated Canary/dev profile, but it also highlights the gap: the smooth path today is to opt out of the real-profile workflow entirely.

I do not think autostart and consent have to be coupled. Silent remote attach should stay off the table, but a bounded consent option like Allow until Chrome exits, Allow for today, or Allow for N hours would still require explicit user action while making reconnect-heavy agent sessions usable. That feels like a better middle ground than choosing between repeated prompts and a separate profile.