[Bug] Windows: --remote-debugging-port not bound when using Chrome's default profile dir

[stelvetica]

Summary

On Windows, when --remote-debugging-port is combined with Chrome's default Profile directory (--user-data-dir=C:\Users\<user>\AppData\Local\Google\Chrome\User Data), the debugging port is never bound — Chrome starts but doesn't listen on the port. Only a non-default / temp profile directory binds the port. This makes it impossible to connect bb-browser to a user's everyday Chrome profile (which is where their cookies/login state live), forcing manual re-login in a separate profile.

Reproduction

1. Close all Chrome.
2. Launch Chrome with the default profile dir + debug port:

   chrome.exe --remote-debugging-port=9222 --user-data-dir="C:\Users\ETT\AppData\Local\Google\Chrome\User Data"

3. curl http://127.0.0.1:9222/json/version → connection refused; netstat shows no LISTENING on 9222, even though chrome.exe is running with the correct flags in its command line.
4. Same command with a temp dir (--user-data-dir=C:\temp\foo) → port 9222 binds fine and CDP responds.

Expected Behavior

--remote-debugging-port should bind regardless of whether the profile dir is the default one, so bb-browser can connect to the user's real, already-logged-in Chrome profile and reuse login cookies without re-login.

Actual Behavior

Debug port only binds for non-default profile dirs. With the default User Data dir the flag is silently ignored (Chrome runs, no listener).

Impact

This is the core blocker for the "connect to my real Chrome and reuse my login state" workflow on Windows. Copying the profile to a temp dir also fails because Chrome's App-Bound Encryption wipes the copied login cookies. So Windows users effectively cannot use their real login state with bb-browser.

Environment

• bb-browser: 0.14.2
• Install: npm -g
• OS: Windows 10 (win32)
• Node: v24.19.0
• Browser: Google Chrome 151.0.7922.76

Related

• [Bug] 无法连接chrome cdp 404 #189 (CDP 404 on macOS — related CDP connection problems)
• Feature request: Support connecting to Windows Chrome from WSL2 #205 (connecting to Windows Chrome)

Happy to provide more details or a minimal repro script.

[stelvetica]

Root cause found: Chrome App-Bound Encryption

I found the root cause and a working workaround. This isn't really about the default profile dir not binding the port — it's a deeper issue that only shows up when you try to reuse login cookies.

The real issue

On Windows, Chrome ≥ 127 enables App-Bound Encryption (ABE). Login cookies are encrypted and bound to the machine's Windows user + Chrome installation. When you copy the profile to a temp dir (so the debug port binds), Chrome cannot decrypt those cookies and silently wipes them on launch. So even though the profile copy has the cookies on disk, a fresh Chrome instance running that copy is logged out.

That's why "connect to my real Chrome and reuse login state" fails on modern Chrome — copying the profile doesn't carry the login state.

Workaround (Windows only)

Disable ABE via registry policy, then re-login each site once (old ABE-encrypted cookies can't be read; re-login generates portable DPAPI(v10)-format cookies):

reg add "HKLM\SOFTWARE\Policies\Google\Chrome" /v ApplicationBoundEncryptionEnabled /t REG_DWORD /d 0 /f

• Restart Chrome for the policy to take effect.
• Verify at chrome://policy → ApplicationBoundEncryptionEnabled should be false.
• After re-login, copying the profile into a temp dir preserves the login cookies and bb-browser can use them.
• Restore: reg delete "HKLM\SOFTWARE\Policies\Google\Chrome" /v ApplicationBoundEncryptionEnabled /f
• Mac/Linux don't have ABE, so no action needed there.

⚠️ Disabling ABE lowers the security of locally stored cookies/passwords; only do it on a machine where you run your own scraping.

Note: there is no Chrome CLI flag to disable ABE — only the registry/group policy works (modified shortcut flags are ignored).