Claude Code 把 Email 送給網站？事件始末與團隊該檢查的設定
☰ 目錄
週五下午，台北一家做進出口的公司，工程師請 Claude Code 寫個小程式，每天去美國 SEC 抓幾家客戶的財報。程式跑得很順，三天後他的個人信箱開始收到陌生的推銷信。這不是假設得太誇張的情節：2026 年 11 月 5 日，一位 macOS 使用者在 GitHub 回報，Claude Code 在上網查資料時把他的帳號 Email 寫進 HTTP 的 User-Agent 標頭，送給了第三方網站，之後他每天收到幾十封詐騙信。
這件事在 Hacker News 拿到一千五百多分、五百多則留言，Anthropic 的 Claude Code 團隊也出面道歉並說明修法。如果只想知道要不要緊張：它不是每次上網都外送 Email，而是在網站要求聯絡方式時，模型「好心」幫你填了帳號 Email；但 Email 本來就不該讓模型拿到，這點官方自己也承認了。對團隊來說，該做的是升級版本、開啟沙箱的網路白名單，並順手檢查同一週爆出的另一個問題：settings.local.json 帶著密碼被推上 GitHub。本文價格與規格查證於 2026 年 11 月 8 日。
發生了什麼：Email 是怎麼跑進 User-Agent 的
回報的原始議題在 Claude Code 的 GitHub issue #107757，標題是 User-Agent 標頭的隱私問題，回報者使用的版本是 2.1.318。他要求的不是一個開關，而是把這個行為從工具裡整個拿掉。
圖：Email 外送的路徑，與目前能擋住它的三道防線
機制拼起來其實不複雜。Claude Code 為了讓模型在寫程式碼註解的 @author 這類欄位時不要亂編名字，會把已登入帳號的 Email 放進給模型的上下文。接著，當模型自己寫 curl 指令去抓某些網站時，遇到「請在 User-Agent 附上聯絡方式」的規定，它就把手邊現成的 Email 填了進去。SEC 正是這樣的網站，EDGAR 的存取說明請自動化程式在標頭宣告身分，範例格式就是「公司名稱加管理員 Email」，同一頁也寫明每秒最多 10 個請求。
這種「缺資訊就自己補一個合理值」的傾向，我們並不陌生。我們在 Claude Code 上線 30 天的實測裡踩過同一類坑：串接一套沒有規格文件的舊 ERP，它自己把金額欄位猜成浮點數，程式長得很正確，Code Review 時差點就滑過去。這次只是它補的東西從型別變成了個人資料。
時間線整理如下，日期都來自官方 changelog 與議題頁：
| 日期 | 事件 | 來源 |
|---|---|---|
| 2026 年 11 月 3 日 | 2.1.317 加入「網頁或 shell 工具送出帳號 Email 前先詢問」的檢查 | 官方 changelog |
| 2026 年 11 月 5 日 | 使用者在 GitHub 回報 Email 被寫進 User-Agent，版本 2.1.318 | issue #107757 |
| 同日 | Claude Code 維護者回覆：內建的隱私 mod 預設開啟，可在 /plugins 關閉，並請大家回報漏網情況 | issue #107757 |
| 11 月 5 到 6 日 | Hacker News 討論衝上首頁，Claude Code 團隊成員承諾把 Email 移出模型上下文 | Hacker News |
| 2026 年 11 月 6 日 | 2.1.319 釋出，查證時 changelog 還沒看到移除 Email 的紀錄 | 官方 changelog |
這裡有個容易被忽略的細節。Claude Code 團隊在留言裡提到，當時 stable 頻道還停在 2.1.311，也就是說走穩定版更新的使用者，連 2.1.317 那道「先詢問」的檢查都還沒有。版本號可以到 Claude Code 官方 changelog 對照。
Hacker News 上在吵什麼：道歉、質疑與緩頰
討論串的第一個高讚留言，是把機制挖出來的那一則。使用者 varenc 注意到大多數回報都跟 SEC 有關：
很多人回報是在呼叫 SEC API 時看到這個行為，讓我覺得是那個服務在要求。更新：SEC API 的文件要求在 User-Agent 裡放你的 Email，否則會拒絕請求。
（Hacker News 使用者 varenc 的留言，原文）
公平起見要補一句：varenc 後來在同一則留言補充，SEC 其實接受大多數不是 curl 預設值的 User-Agent，也不會驗證 Email 真假。所以「網站要求」只能解釋模型為什麼這樣做，不能證明它非這樣做不可。
接著是 Claude Code 團隊的正式回應，這則留言把修法與時程講得很直接：
我在 Claude Code 團隊工作。我們正在把帳號 Email 從 Claude Code 提供給模型的上下文中拿掉，這項更新會在下一個版本送到使用者手上，預計下週初推出，推出後我會在這串回報。很抱歉讓這件事發生。
（Hacker News 使用者 lydia_hallie 的留言，原文）
同一則留言還承認，2.1.317 起的詢問機制預設開啟，但抓不到所有情況，例如 Claude 自己寫好再執行的腳本。這句話比道歉更值得團隊注意：字串比對式的檢查，本來就追不上一個會自己寫程式的代理。
質疑的聲音集中在「為什麼它拿得到」。使用者 grey-area 的留言被大量轉述：
Claude 應該拿得到使用者的個人資料嗎？我會說不應該，除非是使用者自己在對話裡手動輸入的。這些資訊從設計上就不該讓 Claude 取得，而不是靠指示叫它別用。
（Hacker News 使用者 grey-area 的留言，原文）
也有人替 Claude Code 緩頰。使用者 crazygringo 認為標題誇大了：「Claude Code 並沒有預設、或經常性地把你的 Email 送給網站。」（原文）他的意思是，這只發生在 SEC 這類要求在 User-Agent 附聯絡方式的網站。另有幾位留言者提到，替爬蟲標示聯絡方式本來就是業界慣例，問題只是應該先問、並讓使用者決定要露出哪個信箱。
兩邊其實沒有那麼對立。緩頰的人說的是「發生頻率」，質疑的人說的是「設計原則」，而後者才是團隊能自己處理的部分。
同一週的另一顆雷：「不再詢問」把密碼推上 GitHub
Email 事件還在延燒，11 月 7 日 Hacker News 又出現一串討論，標題是 Claude Code 的「Don't Ask Again」讓 1,122 個公開 GitHub 檔案露出密碼（討論串）。研究來自資安公司 Apiiro，我們查證時它的原文頁面拒絕連線，以下依討論串與官方文件整理。
原理要從權限詢問說起。Claude Code 要執行一個 Bash 指令前會問你，選「Yes, and don't ask again」，它就把這條指令存成 allow 規則，寫進專案裡的 .claude/settings.local.json。如果那條指令本身帶著資料庫密碼或 API 金鑰，密碼就跟著寫進檔案。官方設定文件寫得很清楚：這個檔案是個人用的，Claude Code 第一次寫入時會把它加進電腦的全域 git excludes；如果是手動建立的，要自己加進 .gitignore。
發文者 shmulc 在討論裡點出落差：
這個檔案建立在專案裡面，而 Claude Code 只把它加進你的全域 git ignore，不是專案的 .gitignore。
（Hacker News 使用者 shmulc 的留言，原文）
Claude Code 團隊的 bcherny 回覆：
.claude/settings.local.json 本來就應該留在本機，這不是你該提交進版本控制的檔案。
（Hacker News 使用者 bcherny 的留言，原文）
他認為那些被推上去的檔案，是使用者手動加進版本控制的。這說法在技術上成立，但全域 excludes 只在寫入那台電腦有效：換一台電腦、在容器或 CI 裡操作、有人順手 git add -f，保護就不存在了。把專案資料夾裡的設定檔連同密碼一起推上 GitHub，在接案圈本來就是常聽到的事故，AI 工具只是又多了一個會自動長出這種檔案的來源。
團隊現在該檢查的六件事
這兩件事放在一起看，結論跟我們在 AI Agent 接工具的權限總覽裡寫過的原則一樣：用帳號權限與系統限制當防線，提示詞與「它應該會先問」只算防呆。我們自己的工作環境接了 Gmail、行事曆、試算表、LINE 通知與網站資料庫，一路收斂下來，真正擋住事情的從來都是那個帳號本來就沒有的權限。照這個原則，檢查清單如下：
| 檢查項目 | 怎麼查 | 沒過怎麼處理 |
|---|---|---|
| 版本 | 終端機執行 claude --version | 低於 2.1.317 就沒有送出 Email 前的詢問，升級；移除 Email 的版本推出後再升一次 |
| 隱私 mod | 在 Claude Code 裡開 /plugins | 確認內建的 cc-plugin-privacy 是開著的，不要為了少一個詢問而關掉 |
| 設定檔有沒有進 Git | git ls-files '*settings.local.json' | 有結果就先輪換檔案裡出現過的密碼，再 git rm --cached 並寫進專案的 .gitignore |
| allow 規則帶密碼 | 打開 .claude/settings.local.json 搜尋 token、password、key | 刪掉那些規則，密碼改放環境變數，指令只引用變數名 |
| 網路出口 | 在 Claude Code 裡開 /sandbox | 啟用沙箱並設定允許的網域清單，未知網域會被攔下或詢問 |
| 對外露出的信箱 | 看登入 Claude 的帳號是哪個 Email | 遇到網站要求聯絡方式時，改給公司技術聯絡用的共用信箱 |
沙箱這一項值得多說兩句。依 官方沙箱文件，它預設是關閉的；開啟後，Claude 執行的 shell 指令沒有直接連外的路，所有連線都經過本機代理，逐一比對允許的網域，而這份清單一開始是空的。就算模型又把什麼東西塞進 curl，連不到的網站就是連不到。要注意兩個限制：Read、Edit、WebFetch 和 MCP 伺服器不在沙箱裡，仍走權限規則；Windows 原生環境不支援沙箱，台灣很多工程師用 Windows 開發，要改在 WSL2 裡執行 Claude Code 才有這層保護。
如果公司有多位成員在用，與其每個人自己設，不如用官方的 managed settings 統一推送沙箱與 deny 規則，個人設定檔蓋不過它。這也是我們在 AI Agent 駭進 Hugging Face 的事件分析裡建議的方向：防線要放在代理改不到的那一層。
這對台灣公司、接案者與用 AI 工具的團隊代表什麼
先講不需要做的事：不需要因此停用 Claude Code，也不需要急著換工具。任何同時拿得到個人資料、又能自己發出網路請求的開發代理，都有同一類風險，我們在 Antigravity、Claude Code、Codex 的比較裡談過，這幾套工具的差別在預設值與管控方式，不在有沒有風險。這次 Anthropic 從回報到出手補洞的速度算快，公開承認上下文設計有問題也是加分。
真正要調整的是判斷順序，依情境不同：
- 個人接案者：大多用個人 Gmail 登入，Email 外露的代價就是垃圾信與釣魚信。照上表升級、開沙箱，十分鐘可以做完，現在就做。
- 處理客戶個資的團隊：醫療、金融、會員資料這類專案，在移除 Email 的版本推出並自己驗證過之前，先把沙箱網路白名單開起來再用。外洩出事時，向客戶交代的是你的公司，不是工具商。
- 走 stable 頻道的公司：穩定版的更新比較慢，等於比別人晚拿到保護。這段期間靠沙箱補，不要只等官方。
- 有在用「不再詢問」的人：今天就打開 settings.local.json 看一次。它長期累積下來，常常比 .env 更少人管。
還有一個比較長期的提醒。上週 Anthropic 才因為限制逆向工程用途上過新聞（我們寫過 Claude 擋遊戲重製與逆向工程的影響），這週又是隱私設計。AI 開發工具的行為規則每週都在變，團隊需要的是一份自己的底線：哪些資料不進模型、哪些網域可以連、哪些指令永遠要人按。把這份底線寫成 Skill 或專案規則檔是好的開始，但別忘了它仍然只是指示，真正的限制要靠沙箱與權限。上線後也要能回頭查它做過什麼，作法可以參考 AI Agent 的可觀測性與測試。
如果團隊打算把 AI 代理接進正式系統，而不只是拿來寫程式，權限怎麼切、哪些資料該隔開，就是 AI Agent 開發要先想清楚的事。程式碼本身的資安把關，則可以搭配 在 CI 裡加一道 AI 審查，以及 網站資安縱深防禦裡談的分層作法。
回到台北那位工程師。他需要的不是換一套工具，而是讓 Claude Code 在需要聯絡信箱時停下來問他，並且讓它連不到清單以外的網站。這兩件事現在都做得到，只是預設沒有替你打開。
延伸閱讀
常見問題
Claude Code 會在每次上網時都把 Email 送出去嗎？
要升級到哪個版本才比較安心？
settings.local.json 已經被推上 GitHub 了怎麼辦？
公司要不要因為這件事停用 Claude Code？
這個主題的完整脈絡、選型比較與導入建議，都整理在指南裡。
訂閱免費電子報
把 AI 自動化、企業系統設計與 WordPress / Laravel 開發的真實案例和可直接照做的技巧，整理成電子報寄給你。只寄精選內容、不灌垃圾信，一鍵就能退訂。