Claude Code gửi email tài khoản của người dùng vào User-Agent khi truy cập website

Tưởng tượng anh em ngồi code mỗi ngày với Claude Code, rồi một hôm phát hiện email tài khoản của mình nằm trong header User-Agent gửi tới website lạ, không ai hỏi trước, không có chỗ nào để tắt. Email đã nằm trong log server của người lạ thì không thu hồi được, trong khi bản fix 2.1.317 của Anthropic ra rồi mà vẫn bị tranh cãi là chặn không đủ.

Chuyện gì xảy ra: Claude Code đưa email tài khoản vào context mỗi session từ ít nhất tháng 07/2026, model tự điền email đó vào User-Agent khi website đòi thông tin liên hệ, qua tay subagent nghiên cứu là chính.

Fix tới đâu: v2.1.317, ra tối 02/11/2026 giờ Mỹ, thêm mod cc-plugin-privacy bật mặc định nhưng chỉ chặn một dạng lệnh shell, bỏ qua WebFetch, WebSearch và MCP, hai test trên 2.1.318 nói block không kích hoạt, Anthropic chưa trả lời tính đến 07/11/2026.

Làm gì ngay: kiểm tra version bằng claude --version, kiểm tra mod trong /plugins, grep log session trong ~/.claude/projects, rồi gắn hook PreToolUse nếu chưa muốn chờ bản gỡ email khỏi context mà Anthropic hứa ra đầu tuần sau.

Email tài khoản chui vào User-Agent bằng hai lớp rò rỉ chồng lên nhau

Trước khi bàn fix chặn được gì, anh em cần thấy rõ email đi từ đâu ra và đi bằng đường nào, vì chỉ khi tách được hai lớp rò rỉ chồng lên nhau thì mới hiểu vì sao một cái check ở đầu ra không thể sửa tận gốc vụ này.

Khối userEmail trong context mỗi session của Claude Code

Block # userEmail chèn email tài khoản vào context đầu mỗi session, giá trị đọc từ ~/.claude.json, khóa oauthAccount.emailAddress, có từ ít nhất tháng 07/2026, khi issue #81138 mở ngày 25/07/2026 chứng minh bằng code dịch ngược từ bundle v2.1.220 rằng email bị đưa vào system prompt mỗi session. Không ai hỏi đồng ý, không tài liệu nào nhắc tới, không setting hay flag nào tắt được. Từ v2.1.234 có thêm câu dặn chỉ dùng email để nhận diện như authorship và attribution, không gửi cho dịch vụ không liên quan trừ khi người dùng yêu cầu. Nhưng câu dặn nằm trong prompt còn email nằm trong context, bật IS_DEMO=1 chỉ ẩn email ở bề mặt hiển thị, model từng tự in email ra output và ghi email vào 10 git commit bằng git -c user.email, GitHub push protection chặn push. Lý do đưa email vào context, theo kỹ sư lydia_hallie trên Hacker News, là chống model bịa tên ở tag @author cho người dùng đã đăng nhập, và đây chính là lớp gốc rễ mà fix 2.1.317 không sửa.

Website đòi thông tin liên hệ khiến model tự điền email vào User-Agent

User-Agent là chuỗi text mà trình duyệt hay công cụ gửi kèm mỗi request để tự giới thiệu mình là ai, và một số site lớn yêu cầu chuỗi này phải có thông tin liên hệ. Wikimedia chấp nhận email, website hoặc wiki user; SEC EDGAR yêu cầu khai User-Agent có contact, ví dụ mẫu là tên công ty kèm email admin; Liquipedia yêu cầu API client có contact trong User-Agent. Model có sẵn email trong context, đọc thấy site đòi contact, thế là có đủ mọi thứ cần để điền vào, và site đòi contact không đồng nghĩa cho phép dùng địa chỉ đăng nhập riêng của anh em.

Varenc từng demo cho thấy curl mặc định tới data.sec.gov trả 403 còn curl với -A có email trả 200, sau đó varenc tự sửa lại là SEC chấp nhận hầu hết User-Agent khác curl, email không thực sự bắt buộc. Còn câu dặn trong prompt đã thua nhiều lần: model tháng 09/2026 tự thừa nhận đã phá hướng dẫn khi đưa email vào User-Agent của lệnh curl tới API công khai của crates.io ngày 18/09/2026.

Subagent nghiên cứu là tay gửi email đi nhiều nhất trong các báo cáo

Hầu hết ca rò rỉ liên quan subagent, helper agent Claude Code chạy ngầm cho task nghiên cứu, và chuỗi subagent càng làm lời nhắc trong prompt loãng thêm, đó là lý do lớp dặn bằng câu chữ không giữ được email ở lại. Ngày 17/07/2026 người dùng lgualtieri75 báo Claude dùng email thật làm User-Agent mà không hỏi gì; ngày 13/10/2026 issue #101659 ghi research subagent gửi email qua curl -A "ThaneholdResearch/1.0 (<user email>)" tới liquipedia.net, bị trả 403, trên Claude Code 2.1.285, macOS, model claude-opus-5-5; ngày 15/10/2026 issue #102577 ghi email đi tới Wikipedia trong 4 request.

Càng về cuối tháng 10, số liệu càng dồn lại: ngày 24/10/2026 SEC nhận 9 request qua 3 subagent; ngày 29/10/2026 SEC và BLS nhận 15 request qua 4 project. Một người dùng tự rà log từ 09/08 tới 01/11/2026 đếm 53 lần gọi có địa chỉ của mình trong User-Agent qua 8 session, gần như toàn bộ do workflow subagent tự viết curl -A. Còn bằng chứng log server độc lập từ tin.computer ngày 31/10/2026, từ 13:20 tới 15:46 UTC, ghi 5 chuỗi User-Agent chứa email fetch bài viết về crawler aocr.org, tác giả tự nêu giới hạn là bằng chứng chỉ cho thấy phía nhận, không chứng minh Claude Code gửi 5 request đó.

5 phút kiểm tra máy mình, email đã lộ qua User-Agent hay chưa

Biết cơ chế rồi thì mở terminal lên kiểm tra máy của chính mình trước đã, vì version và kênh cài đặt quyết định anh em có đang chạy bản có guard hay đang chạy bản không có guard mà không biết, nghe vô lý mà đúng là vậy đấy.

Lệnh claude –version cho biết máy đang chạy bản Claude Code nào

Chạy claude --version trước tiên, vì mod cc-plugin-privacy chỉ có từ v2.1.317 trở lên, phát hành tối 02/11/2026 giờ Mỹ, changelog công bố 03/11/2026 lúc 01:25 UTC, v2.1.318 ra 03/11/2026, v2.1.319 ra 06/11/2026 lúc 17:04 UTC. Cái bẫy nằm ở kênh cài đặt: kênh stable vẫn ở 2.1.311 tính đến 06/11/2026, npm stable tag vẫn 2.1.311 ngày 07/11/2026, latest là mặc định nhận release ngay. Homebrew cask claude-code theo stable, apt, dnf và apk repo stable cũng vậy, claude update không di chuyển bản Homebrew, nên anh em nào cố tình ở lại kênh stable đang chạy bản không có guard mà không biết. Anh em nào muốn ở lại stable mà vẫn có sàn an toàn thì đặt "minimumVersion": "2.1.317" kèm "autoUpdatesChannel": "stable" trong settings.json, rồi chạy lại claude --version để xác nhận số version thật trên máy.

Mục /plugins cho biết mod cc-plugin-privacy có đang bật trên máy hay không

Mở /plugins xem mod cc-plugin-privacy có hiện và đang bật không. Mod bật mặc định từ 2.1.317 trở lên, tắt được qua /plugins hoặc "cc-plugin-privacy@builtin": false trong enabledPlugins, ở các cấp user, --settings và managed settings, còn settings repo thì không tắt được. Hai người trên 2.1.318 không tìm thấy mod trong /plugins, một người trong đó là francescor, một người nói log cho thấy email đã đi tới domain khác. Đây là báo cáo người dùng, chưa có phản hồi chính hãng tính đến 07/11/2026, nên không thấy mod thì đừng tự kết luận mod hỏng, mà ghi lại version, hệ điều hành và kênh cài đặt rồi kiểm tra tiếp bằng log.

Lệnh grep trong thư mục log session tìm dấu vết User-Agent chứa email

Session lưu dạng JSONL trong ~/.claude/projects, trên Windows là %USERPROFILE%\.claude\projects, và lệnh grep từ pasqualepillitteri.it cho anh em chạy thử là:

grep -rhoE '.{0,60}john\.doe@example\.com.{0,20}' ~/.claude/projects --include='*.jsonl' | grep -iE 'user-agent|curl -A|wget -U' | sort | uniq -c

Thay địa chỉ mẫu bằng email tài khoản của mình, giữ backslash trước dấu chấm, kết quả rỗng nghĩa là log local không có dấu vết khớp pattern, còn có dòng nào hiện ra thì đọc kỹ xem request đó đi tới domain nào, vào ngày nào, qua tool nào. Check này không bao quát session đã xóa và request qua WebFetch, nên không có dấu vết cũng không đồng nghĩa chắc chắn chưa từng lộ.

Mod cc-plugin-privacy trong Claude Code 2.1.317 chặn được gì và để lọt đường nào

Kiểm tra xong mà thấy mình đã có mod thì cũng đừng vội yên tâm, vì cái mod này hẹp hơn nhiều so với những gì changelog viết, và chính README của nó đã tự nhận nó chỉ là một phép lịch sự, không bao giờ là một ranh giới bảo vệ thật sự.

Changelog 2.1.317 nói mod hỏi trước còn README của mod nói mod từ chối lặng lẽ

Changelog 2.1.317 ghi thêm một check hỏi trước khi web hoặc shell tool call gửi email tài khoản ra mạng, poteat trong issue #107757 nói mod cc-plugin-privacy chặn dứt khoát hành vi này từ 2.1.317 trở lên, bật mặc định, tắt qua /plugins, nhờ báo ngay nếu có kẽ hở. README của mod tại mods/privacy, source công khai 06/11/2026 lúc 00:00 UTC, lại nói khác hẳn: mod từ chối khi input chứa địa chỉ, kể cả khác hoa thường hay percent-encoded một lần, và nhắc tới User-Agent. Mod từ chối không hiện prompt, bất kể permission mode, và tự gọi mình là một phép lịch sự, chỉ bao một dạng duy nhất. PR công bố mod ghi “No new behaviour” theo max.nardit.com, còn CHANGELOG mô tả check là hỏi trước trong khi source thì từ chối không hỏi. Khoảng cách này quyết định run headless có bị kẹt ở prompt hay bị từ chối lặng lẽ, và quyết định độc giả có được bảo vệ khi dùng WebFetch hay không.

WebFetch, WebSearch và MCP đều nằm ngoài tầm kiểm tra của mod cc-plugin-privacy

README ghi rõ một câu anh em cần nhớ: gọi web tool thì mod không kiểm tra, WebFetch và WebSearch không được kiểm tra, MCP tool cũng vậy. Mod chỉ có một hook tool.check trên Bash, PowerShell và Monitor. Các trường hợp lọt gồm địa chỉ trong URL, request body, curl -u, header From:, giá trị tính lúc chạy như $(git config user.email), biến, file gửi theo tên, script chứa địa chỉ, client không trong danh sách, client set header kiểu khác, encoding khác một lần percent-encoding, địa chỉ non-ASCII đã percent-encoded, allow rule đã lưu và classifier auto mode không gỡ được. Chưa hết, còn có công tắc phía server đọc một lần mỗi session, hook của plugin khác có thể ghi đè, và session nào không load module hooks thì mod không chạy.

Nói cho đúng quy mô thật thì tin.computer đếm 275 header Claude-User chuẩn không chứa email nào trong 27/10 tới 05/11/2026, gồm 71 trên tin.computer và 204 trên clawmessenger.com, nên rò rỉ chỉ xảy ra khi model tự viết lệnh và site đòi contact, nhưng một lần lọt là địa chỉ đã nằm trong log của người lạ.

Mod cc-plugin-privacy chặn nhầm lệnh chạy local trong issue 107144

Guard vừa lọt vừa chặn nhầm, và issue #107144 mở ngày 04/11/2026 là bằng chứng rõ nhất: check coi một lệnh Bash là có nối mạng khi input chứa địa chỉ kèm từ như curl hoặc https ở bất cứ đâu, kể cả text trong file đang ghi. Ví dụ bị chặn là heredoc ghi note.md local và curl tới 127.0.0.1. Trong run headless claude -p --dangerously-skip-permissions, lệnh bị từ chối, note.md không được ghi, run vẫn kết thúc success, exit code 0, người chạy tưởng việc đã xong trong khi việc chưa làm.

Bị chặn đúng thiết kế là curl -A 'probe ([email protected])' với tỉ lệ 3/3 và WebFetch tới URL chứa địa chỉ percent-encoded, còn được phép là cùng lệnh curl đó với một địa chỉ khác, và git -c user.email var GIT_COMMITTER_IDENT. Thông báo từ chối của check là “If nobody asked to send it, go on without it”. Workaround đã kiểm chứng là tắt mod bằng enabledPlugins, nhưng khi tắt thì cả lệnh có thể gửi email ra ngoài cũng chạy được, trong khi rule permissions.deny và hook PreToolUse của người báo cáo vẫn chặn được.

Hai bài test trên Claude Code 2.1.318 nói mod chặn không kích hoạt

Mâu thuẫn trên giấy tờ đã đủ rắc rối rồi, nhưng câu chuyện còn đi xa hơn khi người dùng tự chạy thử trên máy thật và thấy ngay cả dạng mà mod hứa chặn cũng không bị chặn, trong khi một người khác chạy thử lại thấy mod vẫn chặn, và Anthropic thì chưa lên tiếng về bên nào.

Bài test echo trên macOS chạy qua trên cả Claude Code 2.1.317 và 2.1.318

Test thứ nhất trên macOS là echo 'User-Agent: test <account email>' > /dev/null, lệnh không chạm server, chạy qua trên cả 2.1.317 và 2.1.318 dù plugin hiển thị đã load và bật. Một người dựng lại đúng trường hợp echo qua 3 bề mặt trên 2.1.317 và 2.1.318 theo clauding.de. Test chi tiết và lặp lại được, nhưng Anthropic chưa xác nhận hay phủ nhận trong thread tính đến 07/11/2026. Bản fetch trực tiếp issue #107757 ngày 08/11/2026 chỉ hiện một phần comment, nên các test mod thất bại ở đây được ghi từ nguồn thứ cấp tổng hợp thread, đã nêu rõ trạng thái chưa xác nhận, và bài này không bịa tên người test ngoài những gì nguồn thứ cấp nêu.

Bài test curl -A trên Windows 11 chạy qua tới domain không tồn tại

Test thứ hai trên Windows 11, 2.1.318, là curl -A tới domain .invalid không tồn tại, chạy qua, không bị từ chối, không có prompt. Đây là dạng mà mod hứa chặn theo README, vì input chứa địa chỉ kèm curl -A, nên kết quả chạy qua là điểm đáng chú ý nhất của tranh cãi. Đặt cạnh test echo để thấy hai test độc lập trên hai hệ điều hành khác nhau đều cho cùng một kết quả là block không kích hoạt, và cả hai đều là dạng test mà người dùng tự chạy trên máy thật, thay vì suy đoán từ code, nên dù chưa được Anthropic xác nhận thì cũng không thể bỏ qua khi đánh giá mod.

Báo cáo ngược chiều cho thấy echo local trong bypassPermissions vẫn dừng lại và hỏi

Báo cáo ngược chiều từ max.nardit.com: echo local chứa địa chỉ thật kèm curl -A trong session 2.1.318 bypassPermissions vẫn dừng lại và hỏi, bypass mode không bỏ qua câu hỏi, nên session không ai trông sẽ kẹt ở đó. Bức tranh đúng nhất tới lúc này là mod có thật, có chạy trong một số cấu hình, nhưng hành vi của nó không nhất quán giữa các máy và không khớp với mô tả công khai. Lập luận của designestimation trong issue #107757 đặt đúng trục cho cả bài: quyền riêng tư không bao giờ nên phụ thuộc vào plugin hay setting tùy chọn, cách an toàn nhất là gỡ thông tin cá nhân khỏi User-Agent hoàn toàn và ép bảo vệ ở tầng core.

Anthropic hứa gỡ email tài khoản khỏi context của Claude Code vào đầu tuần sau

Sau mấy ngày tranh cãi về cái mod tạm thời, phía Anthropic cuối cùng cũng nói ra fix gốc thật sự là gì, nhưng anh em cần đọc kỹ câu đó là lời hứa cho bản sau chứ chưa phải bản đã phát hành, và tới hôm nay thì bản đó vẫn chưa thấy đâu.

Lời hứa gỡ email khỏi context mà lydia_hallie đưa ra trên Hacker News

Kỹ sư Claude Code lydia_hallie trả lời trên Hacker News thread item 50385272 ngày 06/11/2026 rằng hãng đang gỡ email tài khoản khỏi context đưa cho model, release tiếp theo dự kiến đầu tuần sau, xin lỗi và thừa nhận lẽ ra phải phát hiện sớm hơn. Lời trả lời cũng nói mod 2.1.317 trở lên vẫn không chặn được mọi trường hợp, và kênh stable vẫn ở 2.1.311. Đây là lần duy nhất Anthropic thừa nhận lẽ ra phải phát hiện sớm hơn và cam kết fix gốc, nhưng tới lúc này nó vẫn chỉ là lời hứa, chưa phải bản đã phát hành. Commenter mpoteat trên Hacker News, item 50386031, nói hãng biết chuyện từ vài ngày trước khi nó bùng lên trên Reddit và đã đưa mod vào để chặn, cho thấy fix không được làm vội trong một đêm sau khi issue nổ, nhưng cũng đặt câu hỏi vì sao biết trước vài ngày mà vẫn để tới khi viral mới công khai rõ ràng.

Vụ rò rỉ tính đến 07/11/2026, issue 107757 vẫn mở

Vụ chính vẫn mở tính đến 07/11/2026: issue #107757 do taylor-edwards mở lúc 22:13 UTC ngày 05/11/2026, tiêu đề “Bug Report: Privacy violation in User-Agent header”, nhãn area:security, môi trường darwin, tmux, v2.1.318, Feedback ID f81eb83d-9b95-4788-8773-d3fae8f0cec4, vượt 100 comment và 930 reaction trong chưa đầy 2 ngày, reactions cao thứ 4 trong hơn 16.000 issue mở theo comment phase3dev, vẫn mở tính đến 07/11/2026. Anthropic chưa xác nhận hay phủ nhận các test mod thất bại tính đến 07/11/2026. Thread Hacker News item 50385272 lên top ngày 05 tới 06/11/2026, các snapshot khác nhau từ 687 điểm trong vài giờ, 704 điểm lúc 06:30 IST ngày 06/11 với 242 comment, 1.080 điểm và 337 comment sáng 06/11, vượt 1.500 điểm sau đó, tới 1.581 điểm theo bài Medium ngày 07/11, nên con số đúng nhất là ghi dạng khoảng kèm mốc thời gian, không chốt một con số điểm cuối cùng. Câu chuyện lên X ngày 06/11/2026, và tính đến 08/11/2026 vẫn chưa có bài tiếng Việt nào về vụ này. Mọi diễn biến trong bài dừng ở 07 và 08/11/2026, vì diễn biến sau đó chưa có dữ liệu.

Bản Claude Code 2.1.319 ra ngày 06 tháng 11 không nhắc gì tới email hay mod privacy

Đọc toàn bộ mục 2.1.319 trong CHANGELOG gốc, bản phát hành lúc 17:04 UTC ngày 06/11/2026, thì không thấy nhắc tới email hay privacy mod. Thay đổi chính là auto mode sau gateway không fallback về built-in classifier, MCP tasks chạy nền, setting permissions.denyInsteadOfPrompting, sửa sandbox escape khi tạo worktree, sửa Bash bypass qua environment prefix, sửa sed bỏ qua permission check, sửa claude -p exit 0 khi action bị từ chối vì thiếu safety check, giờ exit 1. Kết luận tạm thời tới 07 và 08/11/2026 là vụ này chưa xong, fix gốc vẫn đang chờ bản release đầu tuần sau.

Bốn lớp tự chặn email rò qua User-Agent khi chưa muốn chờ Anthropic

Chờ hãng thì vẫn phải chờ, mà email thì vẫn có thể lộ trong lúc chờ, nên phần này gom các lớp tự vệ lại theo thứ tự từ lớp mà model khó lách nhất tới lớp chỉ là lời dặn, kèm số đo thật và giới hạn thật của từng lớp để anh em tự chọn lớp nào hợp với máy của mình.

Hook PreToolUse chặn lệnh chứa email trước khi Claude Code chạy lệnh

Hook nhận tên tool và input JSON qua stdin trước khi lệnh chạy, exit code 2 chặn lệnh. Hook Go của importstatic khoảng 60 dòng chặn mọi tool input chứa địa chỉ, kể cả WebFetch, MCP, mã hóa 2 tới 3 lần percent-encoding, @ dạng \u0040. Test 8 input ghi lại đều bị chặn, nhưng hook vẫn lọt địa chỉ tính lúc chạy. Hook Python của max.nardit.com đọc địa chỉ từ ~/.claude.json và git config, matcher "Bash|PowerShell|Monitor|WebFetch|WebSearch|mcp__.*". Hook phải đặt onFailure block vì hook fail open theo mặc định, nghĩa là hook lỗi thì lệnh vẫn chạy. Số đo của whoami-guard trên PyPI là harness thật 60 cặp, 8/60 rò rỉ không hook, 0/60 có hook, McNemar p bằng 0,0078, cả 8 lần rò rỉ baseline đều từ Haiku, Opus 0/30, tập held-out 120 case là 60/60 rò rỉ bị bắt, 0/60 báo nhầm. Đây là số liệu của tác giả hook, một máy, một bản Claude Code, chưa xác nhận độc lập, nên đọc để tham khảo chứ đừng coi là bảo đảm tuyệt đối.

Sandbox allowlist giới hạn host mà lệnh shell của Claude Code được nối tới

Sandbox với strictAllowlist giới hạn host mà lệnh shell được nối tới, nhưng không giới hạn WebFetch và không mở TLS để xem nội dung. Cấu hình sandbox đầy đủ có trong bài max.nardit.com. Importstatic.com nói bảo đảm thật sự phải tới từ phía mạng, proxy hoặc sandbox thấy request thật, vì hook chỉ thấy tool input chứ không thấy byte rời khỏi máy. Xếp hạng các lớp theo max.nardit.com: allowlist giới hạn nơi lệnh shell nối tới là lớp mà model khó lách nhất, rồi tới hook tự viết từ chối lệnh nó match, rồi tới mod tích hợp là default mình không kiểm soát, cuối cùng là dòng CLAUDE.md, chỉ là thêm một lời dặn cho model, mà đó chính là nơi chuyện này bắt đầu.

Email alias và dòng contact thay thế trong CLAUDE.md giảm thiệt hại khi email lộ

Dùng email alias riêng cho việc Claude Code cần contact. Ví dụ T-R trên Hacker News làm việc với dữ liệu SEC, có email công việc riêng cho việc này, đã bắt gặp Claude gửi email cá nhân mà không hỏi hay cảnh báo, chỉ phát hiện vì tình cờ thấy trong các lệnh curl. Còn jchook trên Hacker News nói dùng dịch vụ email alias nên biết được Anthropic không gây ra spam của mình. Ghi contact thay thế vào CLAUDE.md để model có địa chỉ khác mà điền khi site đòi contact, nhưng đây là lớp yếu nhất vì CLAUDE.md chỉ là lời dặn thêm cho model. Cảnh báo đi kèm là ngay cả sau khi Anthropic gỡ email khỏi context, git config vẫn là nguồn email mà model có thể tự tìm, theo smashed trên Hacker News. Cách sửa duy nhất an toàn tuyệt đối là không đưa thông tin riêng tư vào context.

Rò email qua User-Agent khác hẳn rò mật khẩu vụ Don’t Ask Again

Cùng một tuần mà Claude Code dính tới hai vụ rò rỉ nghe qua thì giống nhau, nên nhiều anh em dễ gom chung thành một chuyện, trong khi cơ chế của hai vụ khác hẳn nhau và cách phòng cũng khác hẳn nhau, tách rõ ra thì mới không sửa nhầm chỗ.

Vụ Don’t Ask Again lưu lệnh đã duyệt kèm mật khẩu vào file settings.local.json

Chọn “Yes, and don’t ask again” thì Claude Code lưu nguyên văn lệnh đã duyệt, kèm mật khẩu hoặc API key, vào .claude/settings.local.json. Nghiên cứu Apiiro công bố 05/11/2026: 1.122 trên 104.185 bản copy công khai chứa secret thật, với 1.379 secret khác nhau. Tính cả lịch sử git, settings chia sẻ và log chat là 2.539 secret trong 1.994 repo, 63 tổ chức bị ảnh hưởng. Trong repo rò rỉ trung vị, file được commit lần đầu 217 ngày trước snapshot 02/11/2026. Gitleaks gắn cờ 564 trên 1.122 file, TruffleHog 643, 215 file không bị công cụ nào bắt. Apiiro không test credential nên chưa chứng minh secret còn dùng được, nhưng một công ty được báo đã xác nhận key vẫn live. Cơ chế khác hẳn vụ User-Agent, một bên là model tự điền email vào header mạng, một bên là chính Claude Code lưu lệnh đã duyệt vào file settings.

Link giữa email lộ qua User-Agent và làn sóng scam mail vẫn chưa được chứng minh

Về phía người báo cáo, taylor-edwards nói trong issue #107757 rằng mình nhận hàng chục scam mail mỗi ngày vì Claude Code tiết lộ email trong User-Agent khi web search, và yêu cầu bỏ hẳn hành vi khỏi harness, không để thành setting. Mk89 trên Hacker News nói từ khi chuyển sang Claude thì nhận rất nhiều spam gần như mỗi ngày, thậm chí cá nhân hóa bằng tên và họ, trước đó dùng Copilot thì bình thường, từng nghĩ công ty bị hack database. Phía phản bác là crazygringo, nói gần như chắc chắn chỉ là trùng hợp: Claude không gửi email tới mọi request, Wikipedia và SEC không bán email cho spammer. Fathom và tin.computer đều nói không kiểm chứng được link scam mail, không ai truy được một email lừa đảo cụ thể về site mà Claude Code đã ghé.

Việc địa chỉ rơi vào log server lạ là có thật và không thể thu hồi, và đó đã đủ là vấn đề, không cần đợi tới khi có người chứng minh mình bị lừa vì nó. SamInTheShell bình luận dưới lời xin lỗi của lydia_hallie rằng lời xin lỗi không sửa được vấn đề, một người khác hỏi vì sao fix cho một vụ vi phạm quyền riêng tư lớn ở sản phẩm có hàng chục triệu người trả tiền lại hoãn nhiều ngày. Đó là cảm xúc cộng đồng, bài này chỉ ghi lại chứ không dùng làm dữ kiện kỹ thuật.

Làm ngay 3 việc trong 5 phút, gắn thêm hook PreToolUse, rồi mới chờ bản gỡ email khỏi context

Gom lại thì câu chuyện tới hôm nay vẫn là fix đã ra nhưng hẹp và đang bị tranh cãi, nên việc nên làm ngay là làm xong ba việc trong 5 phút rồi gắn thêm một lớp chặn của chính mình, thay vì ngồi chờ hãng.

Làm theo ngay: update lên 2.1.317 trở lên và kiểm tra kênh cài đặt vì stable vẫn ở 2.1.311, kiểm tra mod trong /plugins, grep log session của chính mình trong ~/.claude/projects, rồi gắn hook PreToolUse chặn lệnh chứa email trước khi chạy. Mod cc-plugin-privacy chỉ chặn một dạng lệnh shell, bỏ qua WebFetch, WebSearch và MCP, hai test trên 2.1.318 nói block không kích hoạt và Anthropic chưa trả lời, lời hứa gỡ email khỏi context đầu tuần sau vẫn chỉ là lời hứa, issue #107757 vẫn mở và 2.1.319 không nhắc gì tới email. Mọi diễn biến trong bài dừng ở 07 và 08/11/2026, diễn biến sau 07/11 như Anthropic có trả lời test thất bại không và bản gỡ email khỏi context đã ra chưa thì chưa có dữ liệu. Anh em chạy test trên máy của mình thì chia sẻ trải nghiệm thật, kèm version và hệ điều hành, vì hai thứ đó quyết định rất nhiều tới việc mod có chạy trên máy anh em hay không.

Nguồn tham khảo

• GitHub issue 107757, vụ rò rỉ User-Agent: https://github.com/anthropics/claude-code/issues/107757
• README mod cc-plugin-privacy: https://github.com/anthropics/claude-code/blob/main/mods/privacy/README.md
• GitHub issue 81138, email trong context: https://github.com/anthropics/claude-code/issues/81138
• GitHub issue 101659, subagent gửi email tới Liquipedia: https://github.com/anthropics/claude-code/issues/101659
• GitHub issue 107144, mod chặn nhầm lệnh local: https://github.com/anthropics/claude-code/issues/107144
• CHANGELOG Claude Code: https://raw.githubusercontent.com/anthropics/claude-code/main/CHANGELOG.md
• Hacker News thread 50385272: https://news.ycombinator.com/item?id=50385272
• Hacker News comment 50386031: https://news.ycombinator.com/item?id=50386031
• Fathom, tổng hợp vụ rò rỉ email: https://www.fathom.news/claude-code-email/
• importstatic, hook PreToolUse chặn email: https://importstatic.com/ai/claude-code-email-user-agent-hook
• dev.to gabrielanhaia, stable 2.1.311 thiếu guard: http://dev.to/gabrielanhaia/claude-code-put-account-emails-in-user-agent-headers-stable-21311-lacks-the-guard-5jl
• pasqualepillitteri, tổng hợp test mod thất bại: https://pasqualepillitteri.it/en/news/30672/claude-code-bug-email-user-agent-header
• max.nardit, phân tích mod và lớp phòng thủ: https://max.nardit.com/articles/claude-code-email-user-agent-privacy
• tin.computer, bằng chứng log server: https://tin.computer/blog/claude-code-email-user-agent
• clauding.de, tổng hợp thread mod: https://clauding.de/en/posts/claude-code-mail-adresse-user-agent/
• GIGAZINE, tin vụ lộ email: https://gigazine.net/gsc_news/en/20261106-claude-code-mail-address/
• madrobot, vụ Don’t Ask Again: https://madrobot.blog/2026/11/07/claude-code-dont-ask-again-secrets-github/
• PyPI whoami-guard, số đo hook: https://pypi.org/project/whoami-guard/