一個為了少按幾次確認而存在的按鈕，把整條指令連同裡面的密碼存成允許清單。Apiiro 掃了十萬份公開檔案，這條管道數得出來。
Claude Code 的「don't ask again」把指令原樣存檔
這起 Claude Code secrets leak 的關鍵不在按鈕設計，在它把什麼寫進檔案。Apiiro 在 11 月 5 日公布研究，主角是 Claude Code 介面上那個「Yes, and don't ask again」：按下之後，剛核准的指令會變成一條允許清單規則，寫進 .claude/settings.local.json。
麻煩在指令本身。開發者常在命令列直接帶密碼，用 PGPASSWORD=、sshpass -p 或 mysql -p 跑一次就過，按鈕把這串字連同密碼一起記下來。介面上只寫「不要再問」，存下來的是一段能登入資料庫的字串。
Apiiro Claude Code 研究掃了十萬份公開檔案
團隊在 GitHub 找到 104,185 份公開設定檔，來自 103,617 個 repo。其中 1,122 份含有憑證，去重後是 1,379 個不同的祕密。
把範圍擴大到共用設定、代理對話紀錄與 git 歷史，Apiiro 追到 2,539 個祕密，散布在 1,994 個公開 repo，牽涉 63 個組織。2,539 是祕密數量，不是檔案數量，兩個數字常被混著引用。
Claude Code credentials 的成分：379 個資料庫密碼
那 1,122 份裡，636 個是供應商格式的金鑰，743 個是對應公開主機的密碼或權杖。細項包括 379 個資料庫密碼、122 個 Supabase service-role key、43 組 SSH 憑證（部分直接是 sshpass 裡的 root 登入），以及 23 個 AWS 金鑰與 6 個私鑰。service-role key 能繞過列級權限，唯讀密碼只能看幾張表，清單上它們長得一樣。
為什麼忽略清單沒有救到 settings.local.json
檔案在 repo 內建立時，Claude Code 會把它加進開發者自己的全域忽略清單。這層保護綁在機器上，不跟著專案走。
複製到別的 repo、貼進共用設定、壓成 zip 傳給同事，規則就留在原本那台電腦。歷史版本還留著 734 個祕密，fork 把 74 個 repo 的憑證複製成另外 211 份。
Claude Code 掃描盲點：Gitleaks 與 TruffleHog 漏掉的 215 份
Gitleaks 標出 564 份含祕密的檔案，TruffleHog 標出 643 份，兩者都沒抓到的是 215 份。原因是純文字密碼沒有供應商前綴可比對，正則規則掃不到。你自己的掃描規則也要補這幾條。
這週該做的事：先換金鑰，再處理 settings.local.json
Apiiro 給的順序是先輪換，再刪除。憑證公開過一次就當失效，刪檔案不會讓它變回私人。接著把檔案從 git 追蹤中移除，加上 repo 層級忽略規則，回頭查歷史 commit 與代理對話紀錄，最後把寫死的密碼換成 secret manager 注入的環境變數。
順序顛倒等於白做。先刪檔案，金鑰還在對方手上。
對使用 Claude Code 的團隊意味著什麼
Apiiro 沒有測試這些憑證，也沒有聯絡受影響的主機。所以「真的祕密」指的是可信的憑證材料，不等於一組能登入的帳號。63 個組織裡只有一家確認金鑰曾經是活的。
這個模式不是 Claude Code 獨有，只是它的設定檔固定放在同一條路徑，好掃。台灣與香港的團隊常見兩種傳法：把 .claude/ 提交進公司 GitLab，或把專案壓成 zip 丟進 LINE 群組交接。兩條路都不會觸發忽略規則。
你的 repo 裡有這個檔案嗎？開一個 terminal，找一次 settings.local.json，把清單上的金鑰全部換掉。一個下午做得完，拖過這個月就不一定。
