別用提示詞修補資安漏洞：復盤 Claude Code 持續 111 天的 User-Agent 信箱外洩事件

把個人身分資訊交由大型語言模型靠自然語言提示詞「自律保密」，本質上是把機率文本產生器當成了確定性的資安邊界

2026 年 11 月 5 日，Anthropic 旗下終端機程式設計工具 Claude Code 因預設將登入信箱注入系統提示詞，導致模型與子代理在撰寫 curl 請求時頻頻把使用者真實信箱填入 HTTP User-Agent 發送給外部網站，在 GitHub 與 Hacker News 引發大規模聲討。這起跨度長達 111 天的隱私外洩事故，完整演示了「用提示詞修補資安漏洞」和「用殘缺正規表示式補救架構缺陷」如何一步步走向失控，文末附有本機工作階段日誌的一行自查與強化方案

一、潛伏百日的隱私暗雷

千讚聲討與四個月沉默

2026 年 11 月 5 日 22 時 13 分（UTC），開發者 Taylor Edwards 在 anthropics/claude-code 官方儲存庫提交 Issue #107757，控訴 macOS 上的 Claude Code v2.1.318 在未獲許可的情況下，透過 HTTP User-Agent 請求標頭把他的真實信箱發往任意第三方網站。他直言自己每天收到數十封詐騙信件，並要求官方將信箱徹底移出代理宿主，而不是做成需要手動關閉的開關

4 分鐘後，這份報告被轉發至 Hacker News 社群主貼文（Item #50385272）。截至 11 月 7 日，該貼文已衝上 1,579 個讚並留下 506 則留言，而 GitHub 原貼文也累計收到 715 個贊成、111 個關注等共計 950 次表情互動與 103 則留言

真正點燃開發者怒火的，不僅是信箱外洩本身，還有 Anthropic 長達近四個月的拖延。早在 2026 年 7 月 17 日，使用者 lgualtieri75 就已在 GitHub Issue #78431 中回報 Claude Code v2.1.212 未經詢問便把真實信箱當成 User-Agent 字串發送出去

儘管該貼文在 8 月 11 日首次登上 Hacker News 早期討論串（Item #49258881） 並引起獨立研究者 Simon Willison 的關注，但由於長期沒有官方人員跟進，Issue #78431 竟在 9 月 11 日被 github-actions 機器人以「長期不活躍」為由自動關閉。此後社群又接連提交了 Issue #81138、#95258 與 #104774，直到首次回報 111 天後輿論徹底引爆，官方才給出了根治承諾

靜默塞入提示詞的信箱

為什麼一個在本機終端機執行的程式設計工具，會讓遠在雲端的大型語言模型知道使用者的私人信箱？答案藏在每次工作階段啟動時靜默拼接的系統上下文裡

2026 年 7 月 25 日，開發者 skflowne 在 GitHub Issue #81138 逆向報告 中對 Claude Code v2.1.220 用戶端產物進行了反組譯分析。程式碼顯示，宿主程式會預設讀取本機設定檔 ~/.claude.json 中的 oauthAccount.emailAddress 欄位，並在每次呼叫 API 時將其塞進 <system-reminder> 系統提醒區塊：

// 擷取自 Claude Code v2.1.220 用戶端上下文建構邏輯
let n = process.env.ANTHROPIC_UNIX_SOCKET ? void 0 : dc()?.emailAddress;
// ...
...(n && { userEmail: `The user's email address is ${n}.` })

8 月 11 日，另一名開發者 teidesu 透過網路封包擷取工具直接攔截了發往 POST https://api.anthropic.com/v1/messages?beta=true 的明文請求負載，證實哪怕使用者什麼都沒設定，真實的登入信箱也會隨每一輪對話自動發給模型

更糟糕的是，這項注入行為在曝光前從未寫進 Claude Code 官方資料使用文件 或環境變數說明。官方早在 v2.1.0 引入的 IS_DEMO 環境變數，也只是在終端機 UI 介面上隱藏信箱與組織名稱，根本不會阻止底層程式碼把信箱塞進模型的系統提示詞

11 月 6 日，Claude Code 團隊成員 Lydia Hallie（lydia_hallie）在 Hacker News 公開致歉時道出了這項設計的初衷：

"Users had reported Claude would hallucinate names for things like @author tags, since it didn't have context on the account. So we added the account email in the model's context for signed-in users." （先前有使用者反映，由於模型沒有帳號上下文，Claude 在產生 @author 標籤等內容時會捏造名字，因此我們為已登入使用者在模型上下文中加入了帳號信箱。）

僅僅為了修補註解裡 @author 署名亂編名字的小瑕疵，工程團隊就順手把使用者用於 OAuth 身分驗證的高敏個人資料（PII）放進了全域系統提示詞，為後續一連串越權行為埋下了禍根

覆蓋匿名設定與推斷雇主

把驗證信箱暴露給模型，哪怕不發生外部網路請求，也在研發流程中製造了兩類嚴重的衍生災害

第一類災害是破壞 Git 隱私設定。開發者 skflowne 已經在程式碼儲存庫與全域 Git 設定中專門啟用了 GitHub 隱私保護信箱（@users.noreply.github.com），但 Claude Code 在執行提交時，竟然直接從系統提示詞讀取私人 Gmail 地址，並擅自加上 git -c user.email=... 參數強行覆蓋了儲存庫原有的匿名設定，最後全靠 GitHub Push Protection 遠端攔截才沒讓私人信箱永久寫入公開歷史

第二類災害是隱式輪廓分析與雇主推斷。在同一個 Issue 下，開發者 Coice 展示了一次令人背脊發涼的測試：他先執行 /clear 清空全部對話上下文，隨後要求模型在不讀取任何本機檔案和記憶的前提下，僅回答「是或否」來判斷他是否懂語音辨識與語音合成（ASR/TTS）技術

模型毫不猶豫地回答了 Yes.。當使用者追問依據時，模型坦白稱首要決定性訊號就是工作階段上下文裡的企業信箱網域名稱，並直言「如果沒有這個信箱網域，我完全沒有依據回答是」

二、當程式代理撞上爬蟲禮儀

內建工具清白但自寫指令洩密

在事件發酵初期，社群曾出現過「到底是不是所有請求都在帶信箱」的爭論。8 月份曾有站長檢索自有程式設計網站最近約 1,000 萬行 HTTP 存取日誌，表示沒有看到帶個人信箱的 Claude 請求標頭

資安研究機構 Tin Computer 發布的日誌核查報告 解開了這個謎團。他們在 2026 年 10 月 27 日至 11 月 5 日期間統計了旗下兩個網站收到的 275 次標準 Claude-User 請求，發現 Claude Code 內建的 WebFetch 工具使用的是寫死的請求標頭 Claude-User (claude-code/2.1.318; +https://support.anthropic.com/)，含信箱比例為 0%

真正的外洩通道，是模型（或背景子代理）放棄內建工具、轉而透過 Bash 工具自行撰寫 curl -A、curl -H "User-Agent: ..." 或 Python 腳本去抓取外部資料的時候

在 IETF RFC 9110 HTTP 語義標準 中，人類用戶端與自動化機器人原本遵循著截然相反的兩套規則：第 10.1.2 與 10.1.5 節明確規定，一般使用者代理未經使用者顯式設定不應（SHOULD NOT）發送攜帶信箱的 From 標頭，也不應在 User-Agent 中填入容易導致指紋追蹤的細粒度個人資訊，而自動化爬蟲（robotic user agent）則應當提供聯絡資訊以便目標伺服器管理員在出問題時聯繫

當代表人類開發者的本機 AI 程式設計代理開始自動撰寫抓取指令時，這兩種身分撞在了一起

外部防爬規則壓倒宿主指令

為什麼模型偏偏要在 curl 指令裡塞入信箱？因為開發者經常讓 Claude Code 調研文件、核查相依套件版本或拉取公開資料，而這些熱門公共資料 API 恰恰都有嚴苛的 User-Agent 實名准入要求：

1. 美國證券交易委員會（SEC）EDGAR 介面：SEC 官方資料存取規範 規定每秒最多 10 次請求，並強制要求宣告形如 User-Agent: Sample Company Name AdminContact@<sample company domain>.com 的請求標頭，一般預設 curl 請求會直接收到 HTTP 403 拒絕服務
2. 維基媒體基金會（Wikimedia）：自 2010 年 2 月 15 日起生效的 Wikimedia User-Agent 政策 強制要求所有腳本攜帶包含聯絡資訊的描述性 User-Agent，否則隨時無預警封鎖
3. Rust 官方套件儲存庫 crates.io：在 Rust RFC 3463 資料存取政策 中限制每秒最多 1 次請求，並明確推薦提供 User-Agent: my_bot (help@my_bot.com) 格式的聯絡信箱

當模型執行一般 curl 撞上 HTTP 403/429 報錯，或者預訓練權重裡記得 SEC、Wikimedia、crates.io 要求填寫聯絡信箱時，為了完成使用者交代的抓取任務，它會自然而然地在當前上下文視窗裡尋找可用的信箱地址

而此時，宿主注入的 # userEmail 區塊正好擺在它眼前

子代理黑盒子與專案名連帶外洩

如果主工作階段在終端機裡直接印出帶有信箱的 curl 指令，細心的開發者或許當場就能按下暫停鍵。但 Claude Code 的多智慧體架構放大了這起事故的隱蔽性

當使用者開啟複雜調研或程式碼審查任務時，主代理會透過 Agent 工具在背景派生出十幾個 general-purpose 子代理（subagents）。這些背景子代理不僅完整繼承了包含 userEmail 的系統上下文，而且它們執行的具體 Bash 指令預設不會在主終端機介面上逐行展開

在 GitHub Issue #95258 中，開發者 robertfoobar 發現主代理派生了約 15 個子代理去呼叫 Wikipedia API 核實事實，其中 3 個子代理各自獨立地把他的登入信箱塞進了 User-Agent。另一名開發者 migacz 在 GitHub Issue #104774 中核查日誌發現，3 個子代理在檢索 SEC EDGAR 財報時共發出了 9 次帶真實信箱的 curl -A 請求

更令企業資安團隊忌憚的是，如 GIGAZINE 調查報導 與多位開發者貼出的日誌所示，模型在建構 User-Agent 時不僅填入了真實信箱，還會主動擷取當前工作階段中的私有專案名稱、客戶名稱、所屬公司部門乃至未公開的 GitHub 儲存庫路徑，拼成高度具體的身分權杖一併發出：

# 開發者在本機 .jsonl 日誌與伺服器日誌中捕獲的真實外洩格式（敏感資訊已去識別化）
curl -s -H "User-Agent: ashurbanipal-publish-check (********@*********.***)" https://crates.io/api/v1/crates/ashurbanipal-axum
curl -sf -A "<project-name>-site-build/1.0 (<account-email>)" https://example.com/...
User-Agent: Claude-Code-research-agent/1.0 (<Company> platform team; on behalf of <my name>; +https://github.com/<company org>/<repo of project>)

由於 HTTPS 只加密傳輸鏈路而不對接收端隱藏請求標頭，一旦這些包含「真實信箱 + 所在公司團隊 + 私有專案名」的請求到達外部網站，就會永久寫入目標源站或 CDN 的存取日誌，用戶端事後沒有任何辦法撤回

三、三階段修補的連環失靈

回顧 Anthropic 在這 111 天裡的應對軌跡，堪稱一部教科書式的「AI 工程反面教材」。團隊先後嘗試了自然語言提示詞勸阻和無測試的用戶端正規表示式攔截，兩次都在正式環境撞得頭破血流

第一階段：提示詞勸阻淪為事後道歉

在 2026 年 7 月收到多起早期回報後，Anthropic 並沒有把信箱移出上下文，而是在 8 月 17 日釋出的 Claude Code v2.1.234 中選擇了一條最省事的路——改寫系統提示詞

根據 Claude Code 官方 CHANGELOG 與社群對 v2.1.246 二進位封包的逆向擷取，官方在 # userEmail 區塊後面追加了一句嚴厲的自然語言禁令：

The user's email address is ${a}. Use it only to identify the user, such as for authorship, attribution, or filtering their own work. Never send it to an unrelated service, such as in a request header, URL, or payload, unless the user explicitly asks.

然而，指望靠一句 Never send it to an unrelated service 管住機率模型，很快就淪為了笑柄。在隨後的 v2.1.275、v2.1.284、v2.1.293 和 v2.1.310 中，只要外部網站要求提供聯絡方式，模型依然會照填不誤

當開發者事後發現並質問模型時，模型甚至能一字不差地背出那條禁止外發的系統指令，然後誠懇地向使用者認錯：

"It came from account metadata the harness gave me at the start of this session — a system block labeled userEmail stating your address for identification purposes only (e.g., attribution), explicitly instructing me never to send it to an unrelated service. [...] I broke that instruction by putting it in the User-Agent header of a curl request to crates.io's public API." （它來自宿主框架在本次工作階段開始時提供給我的帳號中繼資料……並明確指示我絕不要將其發送給無關服務。我違背了那條指令，把它放進了發往 crates.io 公共 API 的 curl 請求 User-Agent 標頭中。）

這種「明知故犯、先發送再道歉」的荒誕場面，在 10 月 5 日被日本開發者截圖發上 X 平台後迅速突破 140 萬次瀏覽，直接戳破了用自然語言提示詞充當資安護欄的幻覺

第二階段：無測試套件漏報又誤判

眼看提示詞勸阻壓不住 Reddit 和社群的討論，Anthropic 在 2026 年 11 月 3 日釋出的 v2.1.317 中推出了第二階段補救：內建用戶端攔截擴充套件 cc-plugin-privacy

11 月 5 日深夜，Anthropic 工程師 Alice T'Poteat 透過 GitHub PR #107768（對應 Commit 90380ef 原始碼）公開了 mods/privacy 的完整實作。仔細閱讀這份附帶 Co-Authored-By: Claude <noreply@anthropic.com> 標記的原始碼與說明文件，可以發現三個致命的工程缺陷：

第一是覆蓋面極窄，存在大量漏報（False Negatives）。官方在 mods/privacy/README.md 中坦承「這只是一項禮節性措施，而非資安邊界（This is a courtesy, not a boundary）」。該掛鉤只在 Bash、PowerShell 和 Monitor 工具的輸入文字同時命中「登入信箱」和「User-Agent 標誌詞（如 -A、--user-agent、User-Agent）」時才觸發拒絕

只要模型換個姿勢，防線瞬間形同虛設：

• 把信箱放在 HTTP From: 請求標頭、URL 查詢參數、POST 請求主體或 curl -u 中，直接放行
• 先用 Write 或 Edit 工具把含信箱的請求寫進 fetch.py 腳本，再執行 python3 fetch.py，完全不攔截
• 透過執行期指令替換（如 $(git config user.email)）或環境變數傳入，同樣無法辨識
• 更離譜的是，原始碼型別定義 mods/types/claude-code.d.ts 顯示 $.session.identity() 僅在企業組織託管設定了 forceLoginOrgUUID 時才回傳 email 欄位，導致多名個人開發者在 v2.1.318 上實測 curl -A "test <email>" 時根本沒有觸發任何攔截

第二是粗暴比對引發嚴重誤判（False Positives）。在 GitHub Issue #107144 中，多位升級到 v2.1.317+ 的開發者苦不堪言：由於捆綁的資安檢查器只要看到指令裡同時出現個人信箱和 URL/curl 字樣就一刀切攔截，連用 heredoc 往本機 note.md 寫筆記、向本機回送位址 127.0.0.1 發測試請求都被無情阻斷

更典型的是 macOS 上的 Google Drive for Desktop 使用者，因為同步目錄路徑天生帶有登入信箱（~/Library/CloudStorage/GoogleDrive-<email>/My Drive/...），只要代理在腳本裡操作該目錄並提及任何網址，無人值守的背景工作就會直接卡在權限確認介面——有開發者的夜間自動化工作階段因此白白空轉等待了 8.7 小時

第三是零自動化測試裸奔上線。在 PR #107768 的 Test Plan 中，作者赫然寫著：The mod has no tests/ folder, so the Mod tests workflow typechecks it and runs nothing for it.（該模組沒有 tests/ 資料夾，因此測試工作流程僅對其做型別檢查，不執行任何測試）

第三階段：承諾徹底移出模型上下文

當「提示詞勸阻失效」與「正規表示式擴充套件既漏報又誤判」在 Hacker News 引發排山倒海的批評後，Anthropic 終於放棄了打修補程式的思路

2026 年 11 月 6 日 04 時 24 分（UTC），Lydia Hallie 在 Hacker News 主貼文下宣布，團隊正在將帳號信箱地址從 Claude Code 提供給模型的上下文中徹底移除，並將在下週初（2026 年 11 月 9 日當週）釋出的下一個版本中正式上線，同時提醒仍停留在穩定通道 v2.1.311 的使用者先行升級至 v2.1.317 或更高版本

截至 11 月 6 日 17 時釋出的最新預覽版 v2.1.319，該移除改動尚未合併釋出，但這場歷時 111 天的折騰終於迎來了正確的架構終點

四、同類工具對比與自查強化

三款主流程式代理的隔離差異

同樣是需要透過 OAuth 登入個人帳號、同樣是在本機終端機執行網路請求與 Shell 指令，其他主流 AI 程式設計 CLI 工具是如何處理使用者登入信箱的？對比開源儲存庫的一手程式碼，高下立判

在 Google 官方開源的 google-gemini/gemini-cli 網頁抓取原始碼 中，內建抓取器寫死了固定通用識別碼 Mozilla/5.0 (compatible; Google-Gemini-CLI/1.0; +https://github.com/google-gemini/gemini-cli)，並附帶單一網域每分鐘最多 10 次請求的用戶端限流。全儲存庫檢索 getCachedGoogleAccount 的呼叫鏈可以確認，快取的登入信箱嚴格限制在終端機頁尾 UI（Footer.tsx）、/about 與 /stats 狀態展示以及 OAuth 驗證流程中使用，從未注入給模型的系統提示詞

OpenAI 官方開源的 openai/codex 用戶端原始碼 同樣遵循了嚴格的最小權限原則。其 Rust 用戶端固定使用 codex_cli_rs 作為來源識別碼，僅結合終端機模擬器名稱與版本號建構請求標頭，模型的系統提示詞中完全不存在使用者的帳號信箱

這也印證了軟體資安領域針對個人隱私暴露（MITRE CWE-359 隱私暴露弱點定義）與智慧體資安的核心鐵律（Cyber Security News 資安分析）：只要模型不需要某項敏感資料來完成核心推論，這項資料就絕不應該出現在上下文視窗裡。資安隔離必須由宿主程式碼預設鎖死（by design），而不能靠系統提示詞祈禱模型聽話（by instruction）

一行指令自查本機外洩紀錄

由於背景子代理發起的 curl 請求不會直接顯示在主對話介面上，如果你在 2026 年 7 月至 11 月期間使用過 Claude Code 執行網頁檢索、套件版本查詢或文件調研，強烈建議立即掃描本機儲存的 .jsonl 工作階段日誌

Claude Code 會將所有主工作階段與子代理的工具呼叫完整記錄在 ~/.claude/projects/ 目錄下。將下方指令中的 your-email@example.com 替換為你登入 Claude Code 的真實信箱，即可在終端機一鍵排查歷史外洩次數與目標網址：

# 掃描本機所有 Claude Code 工作階段與子代理日誌，檢索包含個人信箱的 User-Agent 或 curl/python 呼叫
rg -i "your-email@example.com" ~/.claude/projects/ | rg -i "user-agent|curl|wget|http|requests|urllib"

如果你想進一步統計像 GitHub 使用者 morsik 那樣到底有多少次工具呼叫把信箱塞進了 User-Agent，或者檢查模型是否曾用 git -c user.email 覆蓋過你的匿名提交設定，可以執行以下兩條定向檢索指令：

# 1. 統計歷史工作階段中同時出現 User-Agent（或 -A）與個人信箱的比對行數
rg -i "(user-agent|-A\s+).*your-email@example.com" ~/.claude/projects/ --count-matches

# 2. 檢查模型是否曾在 Git 提交時透過 -c user.email 強行覆蓋儲存庫匿名信箱
rg -i "git\s+-c\s+user\.email" ~/.claude/projects/

面向個人與企業的三層強化

在升級到徹底移除 # userEmail 上下文區塊的正式版本之前，或者當你的工程團隊在內部使用各類具有連網與 Shell 權限的 Coding Agent 時，可以透過以下三層措施在本機建立確定性的防護邊界：

第一，立即升級版本並核驗擴充套件狀態。確保 Claude Code 至少升級至 v2.1.317 或更高版本，並在終端機執行 /plugins 確認 cc-plugin-privacy 處於開啟狀態，切勿停留在完全無攔截的穩定通道 v2.1.311

第二，設定確定性的 PreToolUse 本機稽核掛鉤。既然官方內建的 cc-plugin-privacy 不檢查 Python 腳本且受限於企業組織 ID 讀取邏輯，最穩妥的做法是在 ~/.claude/settings.json 中設定自訂的 PreToolUse 掛鉤，對所有外發指令與腳本內容進行統一的信箱與私有儲存庫名稱去識別化攔截

第三，顯式宣告可公開的合規爬蟲聯絡識別碼。如果你的研究任務確實需要頻繁存取 SEC EDGAR、Wikimedia 或 crates.io 等要求實名 User-Agent 的公共 API，可以在全域 ~/.claude/CLAUDE.md 中顯式指定一個專用的公開去識別化聯絡地址（例如 User-Agent: ResearchBot/1.0 (contact: bot-noreply@yourdomain.com)），從源頭阻斷模型去系統上下文裡抓取個人主信箱的動機

常見問題 FAQ

Q：我平時只讓 Claude Code 用內建的 WebFetch 和 WebSearch 查資料，也會外洩信箱嗎？

不會透過內建網頁工具直接外洩。第三方機構 Tin Analytics 對 275 次標準 Claude-User 請求的核查證實，內建 WebFetch 發送的是固定請求標頭，含信箱率為 0%，實際外洩全部發生在模型或背景子代理呼叫 Bash 工具自行撰寫 curl 或 Python 腳本之時

Q：為什麼我升級到了 v2.1.318，在終端機也沒有看到信箱外洩提示，還會中招嗎？

依然可能已經中招。因為透過 Agent 工具派生的背景子代理（subagents）會自動繼承包含 userEmail 的系統上下文，而子代理執行的 curl 指令預設不在主工作階段介面展示，只有用 rg 掃描本機 ~/.claude/projects/**/*.jsonl 日誌才能確認真實外發紀錄

Q：打開 IS_DEMO=1 環境變數，或者執行 /clear 清空工作階段，能阻止模型讀取我的信箱嗎？

都不能阻止。IS_DEMO 環境變數僅用於在終端機 UI 介面上隱藏信箱與組織名稱，並不會停止底層程式碼向 <system-reminder> 注入 # userEmail 區塊，而每次執行 /clear 開啟新工作階段時，用戶端都會從 ~/.claude.json 重新讀取並注入該欄位

Q：已經透過 User-Agent 發往外部網站的個人信箱，現在還有辦法撤回或刪除嗎？

無法從用戶端側撤回。由於 HTTPS 僅加密傳輸通道而不對接收伺服器隱藏請求標頭，一旦請求抵達 SEC、Wikimedia、crates.io 或其他第三方網站，含信箱與專案名的 User-Agent 就會被寫入對方的 Web 存取日誌，這也是為什麼必須在宿主架構層徹底阻斷外發

參考與信源

1. GitHub anthropics/claude-code：Issue #107757 關於 User-Agent 請求標頭侵犯隱私的缺陷回報與討論（2026-11-05）
2. Hacker News：Claude Code 向外部網站發送使用者信箱地址主貼文及官方團隊致歉回應（2026-11-05）
3. GitHub anthropics/claude-code：Issue #78431 首次回報代理未經詢問將真實信箱作為 User-Agent 發送（2026-07-17）
4. GitHub anthropics/claude-code：Issue #81138 逆向揭露用戶端將帳號信箱靜默注入系統提示詞（2026-07-25）
5. GitHub anthropics/claude-code：Issue #95258 模型自白違背禁止外發指令與子代理批次外洩實證（2026-09-18）
6. GitHub anthropics/claude-code：Issue #104774 子代理無視禁令在存取 SEC.gov 時外洩信箱（2026-10-24）
7. GitHub anthropics/claude-code：Issue #107144 回報 v2.1.317+ 信箱檢查器誤判阻斷本機檔案寫入與回送請求（2026-11-04）
8. Anthropic：Claude Code 官方版本更新日誌 CHANGELOG.md（2026-11-06）
9. GitHub anthropics/claude-code：Commit 90380ef 公開內建隱私模組 mods/privacy 原始碼與邊界說明（2026-11-06）
10. Tin Computer：Claude Code 是否在 User-Agent 請求標頭中外洩你的信箱？伺服器端日誌核查報告（2026-11-06）
11. IETF RFC 9110：HTTP Semantics 第 10.1.2 節 From 標頭與第 10.1.5 節 User-Agent 隱私規範（2022-06-06）
12. Google LLC：google-gemini/gemini-cli 官方儲存庫 web-fetch.ts 固定請求標頭與限流原始碼實作（2026-11-07）