# Remote debugging port not working in Chrome 136 and later > Since Chrome 136, --remote-debugging-port is ignored on the default profile. Pass --user-data-dir with a folder of its own and the port opens. Source: https://mosaicbrowser.com/blog/chrome-136-remote-debugging ## Chrome 136 stopped remote debugging on your default profile Since Chrome 136, --remote-debugging-port is ignored on the default profile. Pass --user-data-dir with a folder of its own and the port opens. ![The port opens only for a data directory of its own](https://mosaicbrowser.com/covers/chrome-136-remote-debugging.webp) 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](https://developer.chrome.com/blog/remote-debugging-port). 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](https://mosaicbrowser.com/blog/chrome-app-bound-encryption) is the earlier half of the same story.) Mosaic is a desktop app Email yourself the link and open it on your computer. [How it works: Local first](https://mosaicbrowser.com/features/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](https://mosaicbrowser.com/blog/fresh-profile-per-test-run)). ## 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](https://mosaicbrowser.com/features/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](https://mosaicbrowser.com/blog/runtime-enable-detection)). ## Questions ### Why is --remote-debugging-port not working in Chrome 136? From Chrome 136 the switch is ignored when Chrome runs on its default user data directory. Chrome starts and nothing listens on the port. Add --user-data-dir pointing at another folder and the port opens. ### Why did Google make this change? Google's Chrome team said attackers were using remote debugging to pull cookies out of people's real profiles. A non-default data directory uses its own encryption key, so a debugger attached to it cannot read the cookies of your everyday profile. ### Can I still automate Chrome with my own logged-in profile? Not over a remote debugging port on the default directory. Use a separate data directory and sign in there once; the sign-in stays in that folder for every later run. ### Does --remote-debugging-pipe have the same restriction? Yes. Both --remote-debugging-port and --remote-debugging-pipe are ignored on the default data directory from Chrome 136, on Windows, macOS and Linux. ## Related [App-Bound Encryption, and why tools stopped reading Chrome's cookies](https://mosaicbrowser.com/blog/chrome-app-bound-encryption): App-Bound Encryption ties Chrome's cookie key on Windows to Chrome itself, so tools reading the Cookies file broke. Export from inside the browser. [Runtime.enable flips a detector, so we don't call it](https://mosaicbrowser.com/blog/runtime-enable-detection): Runtime.enable detection, measured: one DevTools command turned a clean Mosaic profile into isBot=true on deviceandbrowserinfo. We removed all five calls. [A fresh browser for every test run, and why it should be cheap](https://mosaicbrowser.com/blog/fresh-profile-per-test-run): Leftover cookies and storage are where flaky browser tests come from. A one-time profile gives each run a clean jar and trashes itself when its browser closes. [Running 49 fingerprint tests unattended, and what that takes](https://mosaicbrowser.com/blog/automating-fingerprint-tests): To automate browser fingerprint testing, tell a failed profile from a dead site, an unreadable page and your own bug. Our runner names each across 49 rows. [Local first: your profiles stay on your computer](https://mosaicbrowser.com/features/local-first): Mosaic has no cloud copy of your profiles. Profiles, cookies and proxies stay on your computer, encrypted on disk, with app lock, daily backups and a trash.  [Is Camoufox still maintained? Reading the repository](https://mosaicbrowser.com/blog/is-camoufox-maintained): Is Camoufox still maintained? Its repository answers better than forums do: compare the latest release's date and Firefox base with today's Firefox. [Junglefox and Chroma, Kameleo's two engines](https://mosaicbrowser.com/blog/kameleo-junglefox): Junglefox is Kameleo's Firefox-based engine, beside Chroma, its Chromium one. A Firefox profile needs an engine that really is Firefox, and keeping one is work. ## Mosaic, on your own computer The browser this blog is about: its own Chromium, fingerprints from real machines and a proxy exit per profile. Free holds 3 profiles. Pro is $49 a month for any number. Mosaic is a desktop app Email yourself the link and open it on your computer.