This guide explains how to authenticate with NotebookLM MCP and CLI.
For public HTTP deployment or Claude web/mobile connectors, see Remote MCP Deployment. Remote use introduces a separate MCP endpoint authentication requirement in addition to the Google browser session described here.
NotebookLM uses browser cookies for authentication (there is no official API). The CLI/MCP extracts these cookies automatically from a managed browser session: - Chromium-family browsers use Chrome DevTools Protocol (CDP)
Supported browsers: Google Chrome, Arc (macOS), Brave, Microsoft Edge, Chromium, Vivaldi, Opera.
Two authentication methods are available:
| Method | Best For | Requires |
|---|---|---|
| Auto Mode (default) | Most users | Any supported Chromium-family browser installed |
File Mode (--file) |
Complex setups, troubleshooting | Manual cookie extraction |
This method launches your browser automatically and extracts cookies after you log in.
# 1. Close your browser completely (Cmd+Q on Mac, or quit from taskbar)
# 2. Run the auth command (CLI or standalone)
nlm login # Recommended
# 3. Log in to your Google account in the browser window that opens
# 4. Wait for "SUCCESS!" message
If your DevTools endpoint is slow to respond, you can increase the timeout:
nlm login --devtools-timeout 15
By default, nlm login uses the first available browser. To use a specific browser:
# Set preferred browser
nlm config set auth.browser brave
# Or use an environment variable
export NLM_BROWSER=arc
# Valid values: auto, chrome, arc, brave, edge, chromium, vivaldi, opera
# If the preferred browser is not installed, falls back to auto-detection.
The dedicated browser profile persists your Google login: - First run: You must log in to Google - Future runs: Already logged in, just extracts fresh cookies
This profile is separate from your regular browser profile. Chromium profiles disable extensions.
Use multiple Google accounts by creating named profiles:
# Create profiles for different accounts
nlm login --profile work # Opens browser - log in with work account
nlm login --profile personal # Opens browser - log in with personal account
# List all profiles
nlm login profile list
# Output:
# work: jsmith@company.com
# personal: jsmith@gmail.com
# Switch default profile (no --profile flag needed)
nlm login switch personal
# Output: ✓ Switched default profile to personal
# Use profiles
nlm notebook list # Uses default (personal)
nlm notebook list --profile work # Uses work account
# Manage profiles
nlm login profile rename work company
nlm login profile delete old-profile
Each profile gets:
- Separate credentials: Stored in ~/.notebooklm-mcp-cli/profiles/<name>/
- Separate browser profile: Isolated browser session in ~/.notebooklm-mcp-cli/chrome-profiles/<name>/
- Captured email: Automatically extracted during login for easy identification
This means you can stay logged into multiple Google accounts simultaneously without conflicts.
If your organization uses Google Workspace with a managed NotebookLM instance (e.g., notebooklm.cloud.google.com instead of notebooklm.google.com), set the NOTEBOOKLM_BASE_URL environment variable before authenticating:
# Set the enterprise URL
export NOTEBOOKLM_BASE_URL=https://notebooklm.cloud.google.com
# Then authenticate as usual
nlm login
All CLI commands, MCP tools, and internal API calls will use this URL automatically. If the variable is not set, the default personal URL (https://notebooklm.google.com) is used.
Tip: Add the export to your shell profile (
~/.zshrc,~/.bashrc) so it persists across sessions.
For MCP server configuration, pass the variable in your client config:
{
"mcpServers": {
"notebooklm-mcp": {
"command": "notebooklm-mcp",
"env": {
"NOTEBOOKLM_BASE_URL": "https://notebooklm.cloud.google.com"
}
}
}
}
This method lets you manually extract and provide cookies. Use this if: - Auto mode doesn't work on your system - You have browser extensions that interfere (e.g., Google Antigravity IDE) - You prefer manual control
# Option A: Interactive mode (shows instructions, prompts for file path)
nlm login --manual
# Option B: Direct file path
nlm login --manual --file /path/to/cookies.txt
batchexecutebatchexecute request in the listcookie:The cookie file should contain the raw cookie string from Chrome DevTools:
SID=abc123...; HSID=xyz789...; SSID=...; APISID=...; SAPISID=...; __Secure-1PSID=...; ...
Notes:
- Lines starting with # are treated as comments and ignored
- The file can contain the cookie string on one or multiple lines
- A template file cookies.txt is included in the repository
All data is stored under ~/.notebooklm-mcp-cli/:
~/.notebooklm-mcp-cli/
├── config.toml # CLI configuration
├── aliases.json # Notebook aliases
├── profiles/ # Authentication profiles
│ ├── default/
│ │ └── auth.json # Cookies, tokens, email
│ ├── work/
│ │ └── auth.json
│ └── personal/
│ └── auth.json
├── chrome-profile/ # Chrome profile (single-profile users)
└── chrome-profiles/ # Chrome profiles (multi-profile users)
├── work/
└── personal/
Each profile's auth.json contains:
- Parsed cookies
- CSRF token (auto-extracted)
- Session ID (auto-extracted)
- Account email (auto-extracted)
- Extraction timestamp
Once authenticated, add the MCP to your AI tool:
Claude Code:
claude mcp add notebooklm-mcp -- notebooklm-mcp
Gemini CLI:
gemini mcp add notebooklm notebooklm-mcp
Manual (settings.json):
{
"mcpServers": {
"notebooklm-mcp": {
"command": "notebooklm-mcp"
}
}
}
Then restart your AI assistant.
When you start seeing authentication errors, simply run nlm login again to refresh.
auth_statusThe MCP server_info tool and nlm login --check report one of five
auth_status values from the multi-probe AuthHealthChecker. Knowing the
difference matters: a stale status means you must re-auth, but
an unverified status is a network problem, not a credential problem.
Caching note: the
server_inforesult is cached for 30 seconds (the checker'sCACHE_TTL) and bypassed on the next call if any auth file on disk is rewritten, so an externalnlm loginis reflected without waiting for the TTL.nlm login --checkis always live.
| Status | Meaning | What to do |
|---|---|---|
configured |
Live check passed. Credentials are good. | Nothing. |
not_configured |
No credentials are stored at all (first-time setup). | Run nlm login. |
stale |
Credentials are known-bad: the live check was redirected to accounts.google.com (cookies expired), the on-disk profile failed to load, or the last successful validation is older than 7 days. |
Run nlm login to refresh. Subsequent API calls will fail. |
unverified |
The live check could not be completed (network timeout, DNS failure, proxy block, non-200 HTTP). Cached credentials on disk are still intact and may work for actual API calls. | Retry later, or check your network/proxy. Do not assume the user needs to re-auth — operations often still succeed. |
error |
Unexpected exception inside the check itself (very rare). | File a bug with the traceback. |
Heads up for AI agents: If you see
auth_status = "stale", prompt the user to re-authenticate. If you seeauth_status = "unverified"while recent operations are succeeding, treat it as a transient monitoring failure and continue — re-auth is not required.
Close your browser completely and try again. On Mac, use Cmd+Q to fully quit.
Try file mode instead:
nlm login --manual
Your cookies have expired. Run the auth command again to refresh.
Some browser extensions or tools modify the browser's behavior. Try a different browser or use file mode:
nlm login --manual
Make sure you copied the cookie value, not the header name. The value should start with something like SID=... not cookie: SID=....
nlm loginIf you keep getting "Authentication expired" even after running nlm login or calling refresh_auth, check whether NOTEBOOKLM_COOKIES is set as an environment variable in your MCP config.
Why this happens: When NOTEBOOKLM_COOKIES is set in your config (e.g. claude_desktop_config.json), it takes absolute priority over all other auth sources — auth.json, profile cookies, save_auth_tokens, and nlm login. When those hardcoded cookies expire, no recovery action can fix a running MCP process because the stale env var is baked into its environment.
How to check:
import os
print("NOTEBOOKLM_COOKIES in env:", "YES (overrides everything!)" if os.environ.get("NOTEBOOKLM_COOKIES") else "no")
How to fix (pick one):
NOTEBOOKLM_COOKIES env var from your config entirely and use nlm login instead (recommended — this way auth recovery works automatically)Similarly, if you have NOTEBOOKLM_CSRF_TOKEN or NOTEBOOKLM_SESSION_ID in your config, remove them — both are deprecated and auto-extracted. Stale values can prevent auto-refresh from working.
If nlm doctor auth-replay shows that normal httpx replay fails but
cdp_in_page succeeds, you can opt in to the experimental CDP transport:
NOTEBOOKLM_RPC_TRANSPORT=cdp nlm notebook list
NOTEBOOKLM_RPC_TRANSPORT=cdp nlm query notebook <notebook-id> "Question?"
For MCP clients, add the same environment variable to the server config:
{
"mcpServers": {
"notebooklm-mcp": {
"command": "notebooklm-mcp",
"env": {
"NOTEBOOKLM_RPC_TRANSPORT": "cdp"
}
}
}
}
This runs supported NotebookLM form POSTs through fetch inside the saved
NotebookLM browser profile, so the browser supplies its live cookies. It is
off by default and currently targets normal batchexecute RPCs plus notebook
chat. Uploads, downloads, and artifact file transfers still use the existing
HTTP paths.
If the CDP transport cannot find a saved profile-owned browser session, run
nlm login first. Do not use this flag as a general auth refresh shortcut;
use it only for suspected browser-bound replay failures.
Chrome 136+ (and other Chromium-based browsers at the same version) restrict remote debugging on the default profile for security reasons. This is handled automatically by:
~/.notebooklm-mcp-cli/chrome-profiles/<name>/)--remote-allow-origins=* flag for WebSocket connectionsNo action required from users.
~/.notebooklm-mcp-cli/profiles/<name>/auth.jsonauth.json files or commit them to version controlcookies.txt file in the repo is a template - don't commit real cookies