我的 MCP 伺服器都不是用 managed-mcp.json 定義的，需要擔心嗎？
依 changelog 的字面，這次調整針對的是 managed-mcp.json 裡的 stdio 伺服器，且 ${VAR} 只出現在 env 的那一類。其他來源的伺服器不在這一行的說明範圍內。
不過我沒有逐項驗證各種組合，若你用 managed 設定管控 MCP，升級後還是建議用 /mcp 核對實際載入的清單。
怎麼讓某台伺服器繼續被擋？
依整理的說明，要把它明確寫進 deniedMcpServers。例子中是用 serverCommand 指向該伺服器的執行檔。
寫完後建議開一個乾淨 session，用 /mcp 確認它沒有出現，而不是只看設定檔。
這是 bug 修復還是刻意的政策變更？
changelog 把它列在 Changed，措辭是「停止過濾」，看起來是刻意的行為調整。為什麼這樣改，我沒有查到官方說明。
既然動機不明，更該把它當作需要自己評估影響的變更，而不是等官方解釋。
升級前我能怎麼預先檢查影響？
最直接的做法是打開 managed-mcp.json，找出所有 stdio 伺服器，標出 ${VAR} 只在 env 裡的，再對照白名單看哪些原本會被排除。
這份清單就是你升級後最可能「多出來」的伺服器，逐台決定要不要加進 deniedMcpServers。
Claude Code v2.1.305（2026 年 10 月 20 日）的 Changed 項目寫著：allowedMcpServers 不再過濾 managed-mcp.json 裡那些「${VAR} 只出現在 env 裡」的 stdio 伺服器。這是一個容易被當成小調整的變更，但對用 managed 設定管控 MCP 的管理員來說，方向是放寬，不是收緊。
依第三方整理的說明，升級前（到 v2.1.304），一台 stdio 伺服器如果定義在 managed-mcp.json，而且唯一的 ${VAR} 引用只在 env 欄位裡，不在 allowedMcpServers 白名單上就會被排除。從 v2.1.305 起，這類伺服器不再被白名單過濾，升級後就會載入。要讓它繼續被擋，必須明確寫進 deniedMcpServers。舉例：managed-mcp.json 定義了一台 company-internal，只在 env 用 ${COMPANY_API_TOKEN}，白名單只放一個核可的 npx 套件；升級前它不會載入，升級後會，除非你加上 deniedMcpServers 並指向它的執行檔。
那份第三方整理還指出，官方 managed-mcp 文件描述的白名單過濾範圍似乎比 changelog 這一行更廣，包含 command、args、env、URL 與 headers 裡的 ${VAR} 引用。我沒有親自核對官方文件的這一段，所以這是二手資訊。結論是不要只信其中一邊：升級前，兩邊都看一遍，並用實際環境驗證。
白名單本來的作用是「沒被點名就不載入」。這次調整讓一類伺服器從「預設擋下」變成「預設放行」，除非你另外封鎖。如果這台伺服器帶著內部 API 憑證（像上面例子的 token）卻在你不知情的情況下被載入，影響的不只是功能，還有它能碰到什麼資料。而且這個變化是靜默的：不會有錯誤，只是某台伺服器突然出現在 session 裡。
如果你的團隊用 managed 設定限制 MCP 伺服器，在推 v2.1.305 以上之前，先花十分鐘做一次盤點：找出 managed-mcp.json 中 ${VAR} 只出現在 env 的 stdio 伺服器，判斷它們該不該載入；不該的就補上 deniedMcpServers。升級後再開一個乾淨 session 用 /mcp 列出實際載入的伺服器，與預期比對。多出一台不該有的伺服器，成本通常不在升級當下，而在它被用到的那一天。