Login fails for UK/regional users: cookies set on .google.co.uk instead of .google.com

[AndrewBeniston]

Bug

notebooklm login completes successfully but all subsequent commands fail with:

Error: Authentication expired or invalid. Redirected to: https://accounts.google.com/...
Run 'notebooklm login' to re-authenticate.

Root Cause

For users in the UK (and likely other regional Google domains), the login flow sets auth cookies (SID, HSID, SSID, APISID, SAPISID, etc.) on .google.co.uk instead of .google.com. The notebooklm.google.com API rejects these regional domain cookies.

Storage state after login shows:

.google.co.uk    SID, HSID, SSID, APISID, SAPISID, __Secure-1PSID, ...
.google.com      AEC, __Secure-BUCKET, __Secure-ENID, NID  (no SID!)

The library correctly extracts the SID from .google.co.uk (it's in GOOGLE_REGIONAL_CCTLDS), but when sent as a Cookie header to notebooklm.google.com, the server doesn't accept it — the token value itself is domain-specific.

Fix

Adding cross-domain navigation after the user presses Enter in the login flow forces Google to set .google.com cookies:

# In session.py login(), after input("[Press ENTER when logged in] "):

# Navigate to accounts.google.com to ensure .google.com cookies are set
# (fixes UK/regional users whose cookies land on .google.co.uk)
page.goto("https://accounts.google.com/", wait_until="networkidle")
page.goto("https://myaccount.google.com/", wait_until="networkidle")
# Return to NotebookLM to capture its specific cookies too
page.goto("https://notebooklm.google.com/", wait_until="networkidle")

This triggers Google's cross-domain cookie propagation, resulting in valid .google.com SID cookies in the storage state.

Affected Users

Anyone whose Google login flow routes through a regional domain (.google.co.uk, .google.co.jp, .google.de, etc.) — essentially the same regions listed in GOOGLE_REGIONAL_CCTLDS.

Environment

• notebooklm-py 0.3.3
• macOS, Python 3.12
• UK-based Google account

[teng-lin]

Thanks for the detailed report and the suggested fix — really appreciate the root cause analysis and the cookie domain diagnostic!

What's happening

After login, UK users end up with their SID cookie on .google.co.uk instead of .google.com. The notebooklm.google.com API only accepts .google.com-scoped cookies, so every request fails with the redirect error you saw.

Previous PRs (#24, #34) helped with cookie extraction from regional domains but didn't address this case — the SID value itself is region-scoped and gets rejected server-side, even though our code accepts it without error.

Why other regions aren't affected

We investigated why Singapore and Japan users don't report this. All regional accounts.google.co.* domains redirect identically to accounts.google.com for auth — so the difference isn't about which auth endpoint is used. It's a server-side decision Google makes after login about which domain to set cookies on. Singapore users end up with SID on .google.com; UK users end up with SID on .google.co.uk only. The exact reason is a Google black box (possibly UK GDPR data residency requirements), but the end result is clear from your storage state dump.

The fix

Your suggested approach is correct. We refined it slightly based on research into Playwright's behavior:

# After input("[Press ENTER when logged in] "):

# Navigate to ensure .google.com cookies are set.
# UK/regional users have auth cookies land on .google.co.uk instead of
# .google.com; navigating to accounts.google.com triggers Google's SSO
# to issue .google.com-scoped cookies. Use "load" (not "networkidle") —
# cookies arrive with response headers, and networkidle can hang
# indefinitely on Google's analytics-heavy pages.
page.goto("https://accounts.google.com/", wait_until="load")
page.goto("https://notebooklm.google.com/", wait_until="load")

Two changes from your original suggestion:

• wait_until="load" instead of "networkidle" — Playwright officially discourages networkidle and Google's analytics traffic can cause it to hang for 30+ seconds. Cookies are set via Set-Cookie response headers which arrive before the load event, so "load" is sufficient and much safer.
• Dropped the myaccount.google.com hop — the cookie propagation is driven by accounts.google.com (the identity provider). The extra navigation is likely redundant.

This fix is safe for users in all other regions — Singapore, Japan, US, etc. already have SID on .google.com, so the extra navigations just load authenticated pages with no side effect (other than ~5–10 extra seconds during notebooklm login).

Working on a PR for this now.

[teng-lin]

@AndrewBeniston We've opened a PR for this: #151

Since we don't have a UK-based Google account to test with, would you be able to try it out and confirm it fixes the issue for you?

You can install from the branch directly:

pip install git+https://github.com/teng-lin/notebooklm-py.git@fix/regional-login-cookies

Then run notebooklm login and verify that subsequent commands (e.g. notebooklm list) work without the redirect error. Thanks!