你在 Claude Code 裏點過「Yes, and don’t ask again」嗎？要是點過，而且你當時批准的那條命令裏帶着密碼，那麼你的密碼有可能就在這 1,122 份文件裏面。
安全公司 Apiiro 在 2026 年 11 月 5 日發佈的研究裏，在 GitHub 上按文件名搜 .claude/settings.local.json，一共搜出 104,185 份
裏面有密碼的是其中的 1,122 份，裏面的真的密碼加起來有 1,379 個。
假設你讓 Claude Code 連一次生產數據庫，給它的命令裏就寫着 PGPASSWORD=，後面跟着你的數據庫密碼
它跑這條命令之前會先問你一句，你點了「以後別問了」，它就把這條命令整句存進項目裏的 .claude/settings.local.json，當成一條以後不用再問的規則。下一次再碰到同樣的命令，它直接就跑，不再問你了，而那句密碼也就一直留在這個文件裏，還是明文。
存進去的不一定是整句命令
有的時候它存的是一個模式，比如 npm test * 這種，模式裏沒有密碼，那也就沒事。但是隻要存的是整句命令，那麼命令裏寫了什麼，它就存什麼。研究者拿最新的兩個模型 Opus 5.5 和 Fable 5.1 又試了一遍，試出來的結果是現在的版本照樣會這樣存，所以這不是老版本纔有的問題。
這個文件本來就是給你自己這臺電腦用的，Claude Code 也確實做了保護
它第一次在某個 git 倉庫裏寫出這個文件時，會把這個文件名寫進你這臺電腦的一份全域忽略名單，就是 git 設置裏的 global git excludes。這臺電腦上的 git 看過這份名單之後，在哪個倉庫裏都會跳過這個文件。
可是這份名單隻存在於你這臺電腦的 git 設置裏
這個文件一旦進了倉庫，你的同事把項目拉到他自己的電腦上時，就會把它當成一個普通的項目文件，因爲他的 git 裏沒有這份名單。而且 Claude Code 從來沒有把這個文件寫進項目自己的 .gitignore，所以項目一換電腦，保護就跟着沒了。另外，要是這個文件在被忽略之前就已經提交過，那麼名單也管不了已經進倉庫的那一份。
把這個文件提交上去的，可能根本不是你
研究者追了 1,105 個倉庫。在其中 539 個倉庫裏，改動這個文件的提交把 Claude 列成了共同作者。所以研究者認爲，很多時候是 Claude 在幫你提交代碼的時候，順手把這個文件一起提交了。也就是說，你就算從來沒敲過 git add，這個文件也可能已經在倉庫裏了。
研究者還把這 1,379 個密碼按類型數過一遍
數據庫密碼最多，有 379 個。其次是公網服務器的 SSH 登錄，43 個。再往後是 GitHub、GitLab 和 npm 的令牌，42 個。AWS 密鑰有 23 個。這四類加起來是 487 個，剩下的 892 個，研究者沒有再按類型往下細分數。
這些密碼裏，能直接打開一個數據庫的超過三分之一，數據庫密碼只是其中的一部分
這次一共牽連到 63 個組織。這些密碼裏最扎眼的一例是數據庫廠商自己的管理員級雲密鑰，另一例是醫療記錄數據庫的屬主密碼。研究者對「真的密碼」的判定也不寬鬆：要麼這個密碼長得像已知的密鑰格式，要麼密碼或者令牌旁邊就寫着一個公網服務器的地址，而且還要再過一遍 AI 審覈員的確認，纔算數。
不過，Apiiro 沒有拿這些密碼去逐個試登錄，所以他們證明的是這些密碼被公開了
至於有沒有人已經拿它們登錄過，這份研究沒有證明，所以你不能把這兩件事混在一起說。但是你也不能因此就當沒事，因爲研究者通知到的組織里面，已經有一家回話確認，自家的密鑰在被通知的時候仍然有效。
這些文件也不是剛傳上去的
截至 2026 年 11 月 2 日，裏面有密碼的文件全都還在各自倉庫的默認分支上，而且有一半已經在那兒放了至少 217 天。你就算現在把文件從倉庫裏刪掉，也解決不了，因爲 git 會把舊版本留下來：研究者在舊版本里又找到 734 個密碼，分佈在 509 個倉庫裏。
舊版本之外還有 fork
有 211 個 fork 出自 74 個倉庫，fork 裏帶着的是同樣的密碼，是同一批密碼的副本。團隊成員共用的 .claude/settings.json 裏也有密碼：研究者一共查了 76,011 份，其中 298 份存着密碼。
研究者還在一些倉庫裏存着的聊天記錄裏找到了密碼
當前版本里是 1,379 個，舊版本還多出 734 個，其餘的在團隊共用文件和這些聊天記錄裏，這兩處研究者沒有單獨報數。幾處加起來，研究者一共數到 2,539 個密碼，分佈在 1,994 個倉庫裏。
你可能會想，倉庫不是有密鑰掃描嗎，怎麼沒掃出來
研究者拿 gitleaks 和 TruffleHog 把這 104,185 份文件全掃了一遍。掃完的結果是：在這 1,122 份存着密碼的文件裏，gitleaks 認出 564 份，TruffleHog 認出的更多，有 643 份。兩個工具認出的文件有重疊，合起來一共認出 907 份。剩下 215 份，兩個工具都沒有認出來。
漏掉的主要是寫在命令裏面的密碼
掃描器是按已知的密鑰格式去認的。比如一串長得像 AWS 密鑰的字符串，它就認得出來。但是寫在命令裏的密碼，比如 PGPASSWORD=、sshpass -p 和 mysql -p 這幾種寫法後面跟着的那個詞，看起來就是命令裏一個普通的詞。掃描器分不出它跟其他詞有什麼區別，所以它就直接放過去了。
2025 年 9 月出現過一個叫 Shai-Hulud 的蠕蟲，它感染電腦之後，會在受害者的電腦上跑 TruffleHog 去翻密鑰，而 TruffleHog 正是研究者用的那個掃描器
TruffleHog 能認出這 1,122 份有密碼的文件裏的 643 份，所以誰拿它去翻這些文件，能認出的也是這 643 份。再加上這個文件名是固定的，任何人只要在 GitHub 上按文件名搜，就能一份一份地翻。
2025 年 8 月 11 日，就有人提交了一份 bug 報告，說批准過的命令帶着 API 密鑰和令牌，被原文存進了這個文件裏
這份報告提上去之後，一直沒有人回覆。到了 2026 年 1 月 3 日，因爲已經 60 天沒有動靜，一個自動機器人以「不打算修」把它關掉了。研究者引的相關報告一共有四份，如今全被同一個機器人關掉了，最近的一份關在 2026 年 11 月 6 日。而且按研究者的說法，做 Claude Code 的 Anthropic 對這四份報告一份都沒有回覆過。
研究者還翻了其他 15 個寫代碼的 agent 的文檔，加上 Claude Code 一共對照了 16 個，最後確認只有 Claude Code 會默認把批准過的整句命令存進項目文件裏
所以這不是這一類工具的通病，而是這一個產品的存法有問題。
如果你也天天用 Claude Code，那麼我建議你先去搜一遍：到 GitHub 的組織搜索裏搜 .claude/settings.local.json 和 .claude/settings.json 這兩個文件名，而且要連每個倉庫的 git 歷史一起搜，因爲文件可能已經被刪了，但是密碼還留在舊版本里。
搜到了之後，順序不要搞反
因爲這個文件只要公開過，你就得按它已經被人複製走了來處理。所以先把文件裏出現過的每個密碼、令牌和密鑰都換掉，讓外面那份變成廢的，然後再回頭清理歷史。
清理的時候，你把這個文件用 git rm —cached 從 git 的追蹤裏拿出來，並且把文件名寫進項目自己的 .gitignore
這一步是爲了讓保護跟着項目走，因爲你自己電腦上的那份名單，換臺電腦就不算數了。
你自己電腦上現在的那份文件也要打開看一遍，把帶着密碼的那幾條規則刪掉
以後再碰到要帶密碼的命令的話，你應該先把密碼放進環境變量，命令裏只寫變量名，比如 $DB_URL。這樣就算這條規則被存下來，存住的也只是變量名。你批規則的時候也儘量批模式，比如 Bash(npm run:*) 這種，因爲模式裏不可能夾着你的密碼。
這個文件還會出現在 GitHub 以外的地方
它就是項目文件夾裏的一份明文 JSON，所以它也可能跟着 npm 包、Docker 映像、壓縮包或者同步文件夾被一起發出去。你清理的時候，要把這幾個地方也算進去。
我看完這份研究之後，最放不下的是 217 天這個數字
密碼在公開倉庫裏躺了這麼久，它的主人卻一點都不會知道，因爲從文件被提交到被人搜出來，中間沒有任何一個環節會回來提醒他。在 Anthropic 改掉這個存法之前，能保護你的就只有你自己敲命令之前的那個停頓：密碼要進命令行的時候，你就先把它換成變量，再跑。
要是你也天天和 Claude Code 打交道的話，這類事情我就一篇一篇接着拆給你看。要是你覺得有用，歡迎訂閱這個博客，或者先收藏起來。我會持續分享 AI、安全和開源方面的乾貨。
來源：Apiiro 研究原文 https://apiiro.com/blog/coding-agents-leaking-secrets-github-dont-ask-again ；The Hacker News 報道 https://thehackernews.com/2026/11/claude-codes-dont-ask-again-file.html