Claude Code 按下「不要再問」，資料庫密碼就跟著進了 GitHub：Apiiro 在公開 repo 找到 2,539 組金鑰，台灣開發者今天就該翻的那個檔案

晚上十點，台北一家 SaaS 新創的後端工程師還在追 staging 登入失敗的問題。他請 Claude Code 幫忙連資料庫看看，終端機跳出一行 PGPASSWORD=… psql -h …，問他要不要執行。這已經是今晚第十幾次了，他順手選了「Yes, and don't ask again」，問題修好，push，下班。

這是假設的情境，但資安公司 Apiiro 的研究顯示，這個順手的動作，已經讓上千份帶著真實密碼的設定檔躺在公開 GitHub 上。

事件背景

Apiiro 研究員 Shmulik Cohen 與 Matan Giladi 在 11 月 5 日發表報告，指出 Claude Code 的權限機制有個很日常的漏洞：當你對某個 shell 指令選「Yes, and don't ask again」，Claude Code 會在專案資料夾的 .claude/settings.local.json 寫一條允許規則，之後同樣的指令就不再詢問。問題在於，這條規則有時是一個樣式（例如 npm test *），有時就是整條原封不動的指令。指令裡如果有密碼、token，就以明碼一起存進去。

Anthropic 的官方設定文件也寫得很清楚：這個檔案是「只給你自己、只在這個專案」用的個人設定，Claude Code 第一次在 git repo 裡建立它時，會把它加進開發者電腦的全域 git 排除清單。聽起來有防護，但 Apiiro 指出幾個缺口：全域排除只存在那一台電腦；資料夾後來才變成 repo、換台電腦 clone、或檔案早就被追蹤，都擋不住；而且 Claude Code 從不把它寫進專案自己的 .gitignore。更尷尬的是，在 1,105 個被追到的 repo 裡，有 539 個是由標註 Claude 為共同作者的 commit 動到這個檔案，也就是 AI 自己把它一起 commit 了。

這不是新發現。早在 2025 年 8 月，就有人在 Claude Code 的 GitHub issue 回報同樣行為，後來被自動化機器人以久無動靜關閉。這次 Apiiro 補上的是規模。The Hacker News 11 月 9 日、iTWire 11 月 7 日都報導了這份研究，Hacker News 討論串也衝上六百多分。

本次重點

• 數量：公開 GitHub 上有 104,185 份 .claude/settings.local.json，其中 1,122 份（約 1.1%）含有真實金鑰，共 1,379 組。加上 git 歷史、團隊刻意 commit 的 .claude/settings.json、AI 對話紀錄等，總計 2,539 組、分布在 1,994 個 repo。
• 外洩內容：超過三分之一能直接開資料庫，包括 379 組資料庫密碼、122 把 Supabase service-role 金鑰；另有 43 組公開伺服器的 SSH 登入、42 組 GitHub／GitLab／npm token、23 把 AWS 金鑰。受影響的組織有 63 家，從學生團隊到軟體公司都有。
• 刪檔沒用：舊版本裡還有 734 組目前檔案已看不到的金鑰；211 個 fork 也帶著同樣的密碼。
• 掃描工具會漏：用 gitleaks 與 TruffleHog 掃這 1,122 份檔案，分別只抓到 564 與 643 份，有 215 份兩者都沒抓到。原因是 PGPASSWORD=、sshpass -p、mysql -p 後面的密碼看起來就是普通字串。
• Anthropic 回應：Claude Code 負責人 Boris Cherny 11 月 7 日在 Hacker News 回覆，坦言 Claude Code 過去沒有做密鑰清除，正評估讓 auto mode 攔截、內建基本密鑰掃描等做法，會先做原型再決定。他也強調這個檔案本來就不該進版控，並建議改用 auto mode。截至目前，官方尚未推出修正版本。
• 要打個折扣的地方：Apiiro 沒有實際測試這些金鑰能不能用，只有一家受通知的公司確認金鑰當時有效；Apiiro 本身也在賣應用程式安全產品。數據是該公司的發現，不是獨立複驗。

市場影響分析

台灣使用者

這件事最容易中的，反而是個人開發者、接案工程師和學生。Apiiro 說受影響的檔案大多屬於個人，常見情況是作品集、黑客松專案、課堂作業 repo 設成公開，裡面就躺著連到自己 Supabase 專案或雲端主機的密碼。就算你從沒 commit 過，這個檔案也是明碼 JSON，跟著 npm 套件、Docker 映像檔、zip 壓縮檔或雲端同步資料夾被帶出去的機會一樣存在。

企業應用

對企業 IT 來說，重點不是「禁用 Claude Code」，而是把 .claude/、.cursor/、.gemini/ 這類 AI 代理資料夾，當成跟 .env 同等級的機密檔案管理。Apiiro 也查了其他檔案：團隊共用的 settings.json 有 298 份帶密碼，AI 對話紀錄、記憶檔、交接筆記裡同樣找得到。如果公司的資料庫存有客戶個資，一組密碼外流可能牽涉個資法上的通報與責任問題，實際義務請與法務或專業顧問確認。

另外，不少台灣團隊的 CI 只靠 gitleaks 一類的格式比對，這次數據說明它們抓不到「指令裡的密碼」。不管用哪一套掃描工具，都該檢查規則有沒有涵蓋這類寫法，並把 git 歷史一起掃。

開發者

老實說，這件事的根源是習慣：密碼直接打在指令裡。改成 $DB_URL 這種環境變數，存下來的規則就只有變數名稱；核准時選樣式（例如 Bash(npm run:*)）而不是單一完整指令，也能少存很多東西。這個坑也不是 Claude Code 獨有，Cursor 的對話匯出檔、VS Code 的自動核准設定，Apiiro 也找到含密碼的案例，只是在他們比對的 16 個程式代理裡，Claude Code 是唯一確認「預設把完整核准指令存進專案檔案」的。11 月初我們寫過 Cursor 市集 Claude Code 擴充功能被植入後門 的事件，兩件事放在一起看，AI 代理的設定資料夾已經是攻擊者會翻的地方。

未來發展趨勢

Boris Cherny 的回覆透露了 Anthropic 的思路：與其靠人一次次按核准，不如交給 auto mode 的分類器和沙盒判斷，再補上密鑰掃描。這方向合理，但轉換期會有一段空窗：已經寫進檔案、已經推上 GitHub 的金鑰，不會因為新版本就消失。

我比較在意的是更大的趨勢。AI 代理會「記住」越來越多東西：核准過的指令、對話紀錄、記憶檔、交接筆記，每一份都可能順手記下你的密碼。程式代理越好用、核准越多，這些檔案就越肥，Apiiro 的數據也顯示，超過 8 KB 的設定檔每十份就有一份藏著真金鑰。接下來資安工具勢必會把「AI 代理產生的檔案」列為獨立的掃描類別，企業的 .gitignore 範本也該跟著更新。

TheAI學院 總結與評語

「不要再問」省下的是三秒鐘，存下來的卻可能是一把永久有效的鑰匙；AI 代理記得的東西，你得比它更清楚。

給台灣讀者的具體建議：

1. 今天就搜：在 GitHub 組織或個人帳號搜尋 .claude/settings.local.json 與 .claude/settings.json，連 git 歷史一起查，已刪除的也算。
2. 先輪替、再清理：找到密碼或 token，先在資料庫、雲端、GitHub 後台換掉，再處理檔案。順序反過來，等於把鑰匙留在門上。
3. 斷開追蹤：執行 git rm --cached .claude/settings.local.json，並把它寫進專案自己的 .gitignore，不要只靠全域設定。
4. 打開本機的檔案看一眼：就算沒 commit 過，也把含密碼的規則刪掉。
5. 改掉習慣：指令裡一律用環境變數，核准時優先選樣式規則。想系統化學 Claude Code 權限設定的人，可以參考我們的 Claude Code 使用教學。

資料來源

• Coding Agents Are Leaking Your Secrets to GitHub（Apiiro，2026-11-05，11/8 更新）
• Claude Code settings 文件（Anthropic 官方）
• Claude Code's "Don't Ask Again" File Exposes Passwords and Keys（The Hacker News，2026-11-09）

本文依公開資訊整理，研究數據為 Apiiro 公布結果，Claude Code 的行為與後續修正以 Anthropic 官方文件與公告為準。本文不構成法律意見，涉及個資外洩的通報義務請洽專業法律顧問。