Claude Code email 出現在 User-Agent？先查版本與 privacy mod 邊界
本文目錄
Claude Code 更新到 2.1.317 以上後，還能把帳號 email 放進外送請求嗎？先確認版本與內建 cc-plugin-privacy 狀態，再檢查實際請求；官方 README 只承諾攔截特定輸入形態。 用版本號代替網路驗收，會漏掉工具與資料來源的差異。
issue #107757於 11 月 5 日回報 User-Agent 含 email，回報環境甚至列為 2.1.318。垃圾郵件與這次外送的因果目前屬回報者說法；本文以官方 release、維護者留言與 mod README 說明可確認的部分。
Release 的描述與 mod 的涵蓋範圍分開看
2.1.317 release記載新增 email 外送前的 web／shell 檢查。維護者在上述 issue 表示，該版起內建 privacy mod 預設啟用，可從 /plugins 查看。
但 privacy README描述的是特定 tool.check：Bash、PowerShell 或 Monitor 的輸入同時含帳號地址與已辨識的 User-Agent 字樣／旗標時拒絕。它以字詞匹配運作，連只是並列提及兩者的輸入也可能被攔。
同份 README 明列 WebFetch、WebSearch 與 MCP 未經這個檢查；執行時才計算的變數、由檔名載入的內容、其他編碼與未辨識的 client 也在其範圍外。因此，shell 測試被拒絕，只能驗證該條路徑。若任務要求更完整的外送控管，還需要工具授權與獨立網路政策。
先建立三層紀錄
在自己的外部終端機執行唯讀版本查詢：
claude --version接著在互動式 Claude Code 開啟 /plugins，查看 cc-plugin-privacy 是否存在、啟用。檢閱 user、明確傳入的 settings 與 managed settings，確認 enabledPlugins 中有沒有將 cc-plugin-privacy@builtin 設為 false。README 也列出 server-side switch、較上層已安裝外掛 hook 與未載入 hooks 的 session 等影響因素。
把紀錄拆成三欄：
| 證據 | 能回答的問題 |
|---|---|
| CLI 版本與使用介面 | 這次執行的是哪個 client？ |
| privacy 外掛及設定狀態 | 這個 session 是否具備預期檢查？ |
| 經授權取得的實際 request | 哪個工具、哪個欄位真的送了什麼？ |
若已有外送紀錄，先在本機檢查 hostname、時間、工具類型、header 名稱與去識別後的值。分享 issue 時以佔位字取代 email、Cookie、token 和專案資訊，保留原始版本與重現條件即可。檢查 client 產生的 request 時，也要分清工具呼叫內容與真正送出的 HTTP header。
驗收使用受控目的地
需要動態驗證時，使用自己管理、明確授權的測試接收端與測試帳號。先訂好允許傳送的資料，再分別觀察 shell、web tool 與 MCP 路徑；每條都記錄有無執行、有無抵達及接收內容。依此判斷攔截範圍，並把非必要的工具網路權限收斂到任務所需。
本次本機 claude --version 回傳 2.1.145，未升級軟體、進入新版 /plugins 或重現外送。這篇提供的是文件核對與驗收方法。檔案內容的敏感讀取另有 PreToolUse secret guard；它處理的入口與帳號識別資料外送不同。
參考資料：