Dek: 出問題的地方在專案資料夾裡的一個設定檔，它跟著程式碼一起被 commit 出去。刪掉那個 commit 不夠，金鑰得換。
Claude Code secrets leak 是怎麼被發現的
11 月 9 日，Ars Technica 報導數千組憑證躺在公開的 GitHub 儲存庫裡，來源是 Claude Code 的專案設定檔。同一天，Cybernews 用 AI 代理在 GitHub 上洩漏秘密的角度寫了同一件事，GitGuardian 的分析則把範圍收窄到一個檔名：settings.local.json，並點名 Docker Hub 的憑證是外流的類型之一。
三家講的是同一批檔案。這種事通常不會有受害者名單，因為沒有人被攻擊，檔案是自己被推上去的。
Claude Code settings.local.json 為什麼會進到 commit 裡
這個檔案的位置很關鍵。它住在專案資料夾裡，跟程式碼放在一起，裡面裝的是這個專案的工作設定：允許哪些指令、需要哪些環境變數、接了哪些 MCP 伺服器。它之所以叫 local，是因為本來只該留在本機。
問題出在習慣。開發者每天收工前打一次 git add -A，這個指令的意思是「把所有變動都加進來」，它不會問你哪個檔案不該進。第一次沒有寫進 .gitignore，之後每一次提交都會帶著它。
反過來說，這件事也很容易發生在趕時間的時候。新專案第一天，大家想的是先把東西跑起來，忽略清單通常是第三天補的，而第三天之前已經 push 過三次了。
AI agent secret leak 為什麼比一般金鑰外洩更麻煩
一般的金鑰外洩，通常是一個服務、一組憑證。這次的形狀不一樣：一個設定檔裡可能同時有模型 API key、雲端儲存權限、套件倉庫的登入資訊，還有通知服務的 webhook。一份檔案被打開，等於一整排門的鑰匙一起掉在路上。
第二個差別是檔案長得很像範例。settings.local.json 這種名字不會讓人警覺，它看起來像設定，不像機密。掃描工具也不一定抓得到，因為裡面的值沒有固定的前綴格式。
第三個差別在流通速度。公開儲存庫會被爬蟲與研究人員定期掃描，從 push 到被索引可能只有幾分鐘。台灣有團隊把 side project 放在個人帳號底下，公開了半年才想起來要整理，這段時間足夠讓裡面的東西被抄走。
Claude Code GitHub security：從三個地方開始查
第一個地方是檔名。在你的所有儲存庫裡搜 settings.local.json，包含個人帳號底下的專案，也包含公司組織裡的舊專案。很多人只查最近在寫的那一個，但外洩通常發生在已經沒在維護的那幾個。
第二個地方是忽略清單。打開 .gitignore，確認裡面有這個檔名，也補上 .env 與金鑰檔的規則，這一步防的是下一次，對已經發生的事沒有幫助。
順帶一提，團隊層級要做的是把它寫進範本。每個新專案從同一個 starter 開始，忽略清單就已經在裡面，這比事後要求每個人記得可靠。
第三個地方是提交歷史。用 git log 找這個檔案的紀錄，看它被加進來幾次、有沒有被刪掉又加回來。刪掉又加回來是最常見的情況，因為有人以為刪了就好。
處置順序：先換金鑰，再談歷史
順序不能反。金鑰一旦進了公開儲存庫，就當作已經外流。改寫歷史、force push、把儲存庫設成私有，這些動作都只影響之後的訪客，不影響已經抓走的那一份。
實務上的順序是這樣：先到每個服務的後台撤銷舊憑證、發出新的，再把新值放進本機的環境變數或密鑰管理服務，最後才處理 git 歷史。歷史要不要清，取決於儲存庫是不是公開、有沒有對外公告過。
還有一個常被跳過的步驟：查帳單與存取紀錄。金鑰被拿走之後，最容易被用來跑的是模型 API 與雲端算力，那些花費不會立刻出現，通常要等到下一期帳單。香港有團隊遇過類似情況，發現時帳單已經多了一截，而原因只是某個早已廢棄的專案。
這次事件沒有證明的事
第一，Claude Code 本身沒有被入侵。這是使用者自己提交的設定檔，不是產品漏洞，兩者的應對方式完全不同。
第二，報導說的是數千組，沒有更精確的數字，任何比這個更具體的說法目前都沒有依據。
第三，不是每一組外流的憑證都還有效。有些可能早就過期，有些可能只是測試用的字串。這也是為什麼清查要從服務後台做，而不是從檔案內容猜。
第四，Anthropic 有沒有打算預設忽略這個檔名，目前沒有公開說法。AI 代理的工具鏈還在長，這一類預設值該由誰負責，會是接下來幾個月的問題。
在那之前，能做的就是把搜尋做完、把金鑰換掉、把忽略規則補上。三件事加起來大概一個下午，比事後對客戶解釋便宜太多。要不要現在就動？如果你的組織裡有人這半年碰過 Claude Code，答案是要。
