Highlights
This is a maintenance release. No new user-facing features, but a real bug got caught and fixed, plus the kind of internal cleanup that makes the next batch of features land faster.
Long-running MCP servers pick up new tokens immediately
If you run notebooklm-mcp as a persistent server, the 0.6.14 release added a 60-second cache around the auth check. Good for performance, bad in one specific case: if you ran nlm login to refresh tokens while the server was running, the server kept using the old tokens for up to 60 seconds after.
The fix watches the auth files on disk. As soon as nlm login writes fresh cookies to any profile, the server notices the file change and re-validates auth on the next call. No restart, no refresh_auth dance, no waiting for the TTL to expire.
If you run the CLI in a long agent loop, this also matters: an external nlm login (say, from a separate process or terminal) no longer leaves you stuck on stale tokens for a minute.
A bug in the bug fix, caught by live testing
The honest version: the first attempt at the mtime fix watched the wrong file. It looked at the legacy auth.json instead of the modern profiles/<name>/cookies.json layout that this project has used since the v0.3.0 multi-profile refactor. All 916 unit tests passed because the tests used a mocked file path. The bug only showed up when I ran the real flow: nlm login --profile personal --check (warms the cache), then nlm login --profile personal --force (rewrites the profile's cookies), then nlm notebook list (should use the new cookies but didn't, because the guard was watching a different file).
So the second iteration of the fix stats every cookies.json under profiles/, plus the legacy auth.json, and uses the max mtime. A write to ANY of them invalidates the guard, regardless of which profile the active session is using or which profile the config's default_profile points to.
This is exactly the kind of bug that hides behind green unit tests forever and only shows up in production. The fix is in. If you maintain a long-running MCP server, this is the release to upgrade to.
Internal cleanup: services layer for auth
Every cli/ and mcp/ file that needed check_auth, AuthManager, or related helpers used to import them directly from core/. The codebase has a layering rule (cli/ and mcp/ go through services/, never core/ directly) and 11 of those imports were breaking it. The 0.6.14 release fixed one of them. This release fixes the other 10.
services/auth.py is now a real shim with 7 exports: check_auth, load_cached_tokens, save_tokens_to_cache, get_cache_path, validate_cookies, plus the two class symbols AuthTokens and AuthManager (via PEP 562 __getattr__, which preserves isinstance checks and lets tests monkeypatch the core class without having to patch the re-export).
No behavior change for users. The point of the exercise is that when the next auth refactor lands, only the shim needs to change, not 11 call sites.
The only remaining direct core.auth import in cli/ or mcp/ is in utils/cdp.py, which has a circular-import guard and is intentionally outside the layering rule's scope.
Update
uv tool install --upgrade notebooklm-mcp-cli
# or
pip install --upgrade notebooklm-mcp-cliCredits
No community PRs in this release. It was a me-and-the-test-suite affair. The unit tests passed on the first try. The integration test (which I wrote after shipping 0.6.14, prompted by your pushback on the prior fix) caught the real bug. This is what "test before shipping" is for, and I'm glad we did it.