Chrome 136 stopped remote debugging on your default profile

From Chrome 136, --remote-debugging-port and --remote-debugging-pipe do nothing when Chrome runs on its default user data directory. Chrome opens as usual and nothing listens on the port, so Puppeteer, Playwright or curl http://127.0.0.1:9222/json/version get a refused connection. The fix is one more switch: --user-data-dir pointing at a folder of its own.

# macOS
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \
  --remote-debugging-port=9222 \
  --user-data-dir="$HOME/chrome-debug"

On Windows the same two switches go after chrome.exe, with a path such as C:\chrome-debug. Any folder that is not Chrome's default works. Chrome creates it on first launch.

Why Google turned it off on the default profile

The Chrome team explained the change in its post on the remote debugging switches. After App-Bound Encryption made Chrome's cookie key on Windows hard for other programs to get, attackers moved to the next door: start the user's own Chrome with a debugging port and ask it for the cookies over the DevTools protocol. Chrome would decrypt them itself, because the request came from inside the browser.

Ignoring the switches on the default directory closes that door. A non-default directory gets a different encryption key, so a debugger attached to it sees only what was signed in there, never the everyday profile with your mail and bank in it. The change covers Windows, macOS and Linux. (App-Bound Encryption is the earlier half of the same story.)

How it works: Local first

Remote debugging port still not working? Two other reasons

If you already pass --user-data-dir and the port is still closed, check these:

1. Chrome was already running on that directory. A second launch hands the command line to the process that owns the folder and exits, and the running process does not open a debugging port it was not started with. Quit every Chrome window on that directory first, or use a directory no running Chrome owns.
2. The path is the default one written differently. Pointing --user-data-dir at Chrome's own folder, for example ~/Library/Application Support/Google/Chrome on a Mac, is still the default directory, and the switch is still ignored.

When it works, curl http://127.0.0.1:9222/json/version returns a JSON object with a webSocketDebuggerUrl, and that is the address a client attaches to.

A separate directory starts empty

The new folder is a new profile: no cookies, no saved logins, no extensions. That is the point of the change, so copying your default profile's files into it is fighting the protection rather than working with it. Sign in once inside the debugging directory instead. The cookies stay in that folder, and every later launch with the same --user-data-dir starts signed in.

If you run tests, an empty directory per run is often what you want anyway, because results from a browser that carries last week's cookies are hard to repeat (why a fresh profile per test run should be cheap).

How Mosaic launches with a debugging port

Every Mosaic profile has always been a separate data directory, so the Chrome 136 change did not touch us. Each launch of Tesseract Chrome, our own Chromium, gets --user-data-dir set to that profile's own folder and --remote-debugging-port set to a free port on 127.0.0.1. Starting a profile through the local REST API (a Pro feature) returns its DevTools endpoint, and Puppeteer and Playwright attach to it like any Chrome.

On a Mac, a Mosaic profile's cookies are not encrypted with a key from the login keychain. Each profile's cookie key is derived from Mosaic's data key and the profile's id, so a profile folder copied to another machine carries no key with it, and cookies stay on your computer (local-first covers what is stored where).

Attaching is not the only thing a site can notice. Some bot tests read whether the DevTools Runtime domain has been switched on, which Playwright does by default, so Mosaic drives pages without enabling it (why we never call Runtime.enable).