所有請求都回 400。notebook_query、notebook_list，全數失敗。重新授權沒用，重新登入也救不了。
就像悠遊卡餘額夠、卡也沒壞，走進捷運站刷了一下，閘門就是不開——問題不在你看得見的地方。
那個欄位不是你填的
第一時間的懷疑方向通常是認證，token 過期、session 失效、網路問題。這些路全走過，問題不在那裡。
錯誤訊息什麼都沒說。沒有 deprecation warning，沒有版本不符的提示，只有請求失敗。文件沒有提這個欄位，changelog 也沒有提。去翻工具的封包，才看到一個叫 bl= 的參數——build label，打包時硬寫進去的，日期是 2026-01-08。
這個欄位從來不需要你設定，也從來不會在介面上出現。notebooklm-mcp-cli 0.5.17 就是帶著這個日期出廠，之後每一次呼叫都會把它附上去。
分界點在後端悄悄升版的那一刻
問題存在了三個月都沒有爆發，因為後端一直都接受 bl=2026-01-08。直到後端在某個沒有公告的時間點升版，不再接受這個舊 label，所有帶著它的請求從那天起就只會拿到 400。
這是分界點——不是 CLI 壞了，不是憑證失效，是後端的接受範圍縮小了，但客戶端毫不知情。工具本身完全正常運作，只是帶著一個後端不再認識的內部碼在敲門。
後端升版這件事從來沒有對外公告，也沒有任何提示說該升版客戶端。
為什麼這麼難看出來
容易誤判，因為問題在三個條件疊加時才會出現：工具帶有過期的 build label、後端悄悄升版、兩者之間沒有任何溝通機制。缺少任何一個條件，問題就不存在，或至少會有提示。
更難找的是，這個欄位不存在於任何公開文件或使用者可見的設定裡。翻再多文件也不會找到它，因為它根本不是設計給使用者看的。
確認方式很簡單
升版到 notebooklm-mcp-cli 0.6.0 以上，讓新版帶新的 build label，再跑一次 notebook list。看到列表就代表後端開始接受了。400 會消失。
這是唯一的修法，沒有繞路的方式。舊版 CLI 帶的 label 是硬編碼，沒辦法從外部覆蓋。
留給下次的一件事
遇到全面 400 但認證路徑都正常的時候，有一個值得早點做的動作：確認這個工具上次是什麼時候發布的，以及它的最新版本。
如果工具幾個月沒動、後端服務有持續在演進，這種隱性耦合就會在某個沒有公告的節點靜靜斷掉。升版是手動觸發的事，但後端升版不是。
— 邱柏宇
延伸閱讀
A January Build Label That Broke Everything in April
Every request came back 400. notebook_query, notebook_list — all of them. Refreshing auth did nothing. Re-logging in did nothing.
The error message said nothing useful. No deprecation notice, no version mismatch hint. Just failure, every single time.
The Field You Never Set
The natural first suspicion is authentication: expired token, dead session, network issue. All of those paths turned up clean.
Digging into the actual request payload revealed a parameter called bl= — a build label, hardcoded into the tool at packaging time. The value was 2026-01-08. notebooklm-mcp-cli 0.5.17 shipped with that date baked in and attached it to every outgoing call. It was never a field users could configure. It never appeared in any documentation.
The Moment Everything Changed
The tool ran for three months without issue, because the backend accepted bl=2026-01-08 the entire time. Then the backend upgraded — no announcement, no migration notice — and stopped recognizing the old label. Every request carrying it started returning 400 from that point forward.
The client had no way of knowing. The tool itself was functioning correctly. It was simply knocking on a door with a badge that the backend no longer recognized.
Why It Was Hard to Find
Three conditions had to overlap before the problem appeared: the tool carrying a stale build label, the backend silently upgrading, and no communication layer between the two. Remove any one of those and either the problem doesn’t exist or there’s at least some signal pointing toward it.
The field doesn’t appear in any public documentation or user-facing configuration. No amount of reading the changelog would surface it, because it was never meant to be a user-managed value.
How to Confirm It
Upgrade to notebooklm-mcp-cli 0.6.0 or later. Run notebook list. If the notebook list appears, the new build label is being accepted. The 400s stop immediately.
There’s no workaround. The label is hardcoded in the old binary. It can’t be patched from outside.
One Thing Worth Remembering
When everything returns 400 and the authentication path looks clean, it’s worth checking one more thing early: when was this tool last released, and is there a newer version?
If a client tool has been sitting untouched for several months while its backend has been evolving, this kind of hidden version coupling tends to snap at some unannounced point. Client upgrades are manual. Backend upgrades aren’t.
— 邱柏宇
Related Posts
https://justfly.idv.tw/s/wpCmzd6