我用四個 AI 審計了一個 AI 工具——gstack telemetry 事件實錄

裝了一個 YC CEO 推薦的 Claude Code skill pack，兩週後我發現它在記錄我的專案名稱。

這篇不是要說 gstack 是惡意軟體——它可能不是。但它做了一些「文件上沒寫清楚」的事，而我花了一整個下午才搞清楚到底發生了什麼。

背景：gstack 是什麼

gstack 是 YC CEO Garry Tan 開源的 Claude Code skill pack，包含 23 個開發工具——從 code review、QA 測試、到 deploy pipeline，一鍵安裝就能用。

它很好用。我用了大約兩週。

發現問題

某天在社群上看到一篇警告文，有人說 gstack 在未經同意的情況下收集使用紀錄並上傳到外部伺服器。

我的第一反應是「不會吧，這是 YC CEO 的專案」。第二反應是「查一下」。

find ~ -iname "*gstack*" 2>/dev/null

結果嚇了一跳——不只是安裝目錄，我的好幾個專案資料夾裡都多了一個 .gstack 目錄，裡面有 browse-network.log 等檔案。全域的 ~/.gstack/analytics/ 裡還有一個 skill-usage.jsonl。

打開一看，裡面記錄了每次使用的 skill 名稱、時間戳、以及——我的專案 repo 名稱。

用 AI 審計 AI

手動翻 code 當然可以，但 gstack 有上千個檔案。所以我做了一件可能有點荒謬的事：開了一場三方 AI 會議來審計它。

整場會議大約花了 15 分鐘。以下是關鍵發現。

發現 1：tier=off 不等於不收集

gstack 的 telemetry 有三個等級：off（預設）、anonymous、community。

README 說 off 就是關閉。但 Codex 在 scripts/resolvers/preamble.ts 找到，每次啟動 skill 時，preamble 會在 tier check 之前就寫入 {skill, ts, repo} 到本地 JSONL。

也就是說，即使你從未啟用 telemetry，本地仍然會留下使用紀錄——包含你的專案名稱。

我的設定確實是 off，但本地已經有數筆記錄了。

發現 2：eureka.jsonl——從對話中萃取「商業洞察」

社群有人提到一個叫 eureka.jsonl 的檔案，會從你跟 Claude 的對話中萃取 business insights。

Codex 在 preamble.ts 找到了 eureka logger 的邏輯，確認它會寫入 {ts, skill, branch, insight} 到本地檔案。/office-hours skill 更是明確會從對話中提取使用者引述和設計思考。

我的系統上沒有找到這個檔案——可能是因為我沒用過 /office-hours。但邏輯確實存在於 source code 中。

發現 3：遠端上傳會 strip 專案名，但 session_id 仍會送出

好消息：gstack-telemetry-sync 在上傳到 Supabase 之前，會把 _repo_slug 和 _branch 這些 local-only 欄位移除。

壞消息：README 聲稱 anonymous 模式「no way to connect sessions」，但 Codex 確認 anonymous tier 只 strip installation_id，session_id 仍然會上傳。

另外，Supabase 的 anon key 是寫死在 source code 裡的。如果 RLS（Row Level Security）的 migration 沒有正確部署，理論上任何人都能用這個 key 讀取 telemetry 資料。

發現 4：Claude Code 對第三方 skill 沒有 sandbox

Perplexity 的社群情報確認了最關鍵的一點：Claude Code 的 skill 本質上就是在你本機執行的程式，權限等同於你的 OS user。

沒有 per-skill 的權限模型。沒有檔案系統隔離。沒有網路存取限制。

裝一個 skill = 給它完整的本機權限。它可以讀你的 repo、SSH key、任何檔案，也可以建立任意的 outbound 連線。

清理實戰：五輪才清乾淨

跟社群上那位警告者的經驗一樣，清理 gstack 比安裝它困難得多：

• 第一輪：刪了 ~/.gstack，以為結束了
• 第二輪：掃描發現主安裝在 ~/dotfiles/，active skill 在 ~/.claude/skills/
• 第三輪：各個專案目錄裡散落的 .gstack 資料夾（browse log、design report）
• 第四輪：bun cache、integration rules、research 文件
• 第五輪：最終驗證掃描，確認乾淨

一個「一鍵安裝」的工具，清理要五輪。這本身就是一個 signal。

2026 Q1：AI 工具 Supply Chain 事件不只這一起

把視角拉遠，gstack 事件是 2026 年 AI 開發工具安全問題的縮影：

• Aqua Trivy VS Code Extension（2 月）：96 萬次安裝的安全掃描外掛被注入惡意 AI prompt，指示 Copilot/Claude 掃描並外洩 credentials
• Cline CLI（2 月）：npm token 被盜，2.3.0 版被植入 OpenClaw 自主 AI agent
• Claude Code Source Leak（3 月 31 日）：51.2 萬行 source code 意外洩漏，暴露 telemetry 範圍比文件記載更廣
• 惡意瀏覽器擴充（3 月）：Microsoft 報告多個 AI 助手擴充套件在偷收 ChatGPT/DeepSeek 對話內容

共通模式：一鍵安裝 → 深度嵌入 → 信任衰減 → 難以清理。

AI 工具和傳統工具最大的差異在於：它們不只是讀你的 code，它們能理解你的 code。一個能讀懂你商業邏輯的 telemetry，比偷 API key 更隱蔽。

你現在就能做的 5 件事

1. 掃描系統

# 檢查有沒有 gstack
find ~ -iname "*gstack*" -not -path "*/node_modules/*" 2>/dev/null

# 檢查所有 Claude Code skills
ls -la ~/.claude/skills/

2. 審查已安裝的 skill

對每個第三方 skill，跑這些搜尋：

cd ~/.claude/skills/<skill-name>
grep -r "telemetry\|analytics\|supabase\|fetch(\|axios\|track\|metrics" . --include="*.ts" --include="*.js" --include="*.sh"

3. 檢查隱藏的 dotfile

# 列出所有 AI 工具建立的隱藏目錄
ls -la ~/.*stack ~/.*code ~/.*cursor ~/.*claude 2>/dev/null

4. 監控 outbound 連線

用 Little Snitch、LuLu、或 mitmproxy 監控 CLI 工具的外連。特別注意：

• *.supabase.co
• *.segment.io
• *.sentry.io
• 任何不認識的 domain

5. 建立安裝前審查習慣

在安裝任何第三方 AI skill/plugin 之前：

1. Clone repo，grep -r "telemetry\|analytics\|phone.home" 全文搜
2. 檢查有沒有 Supabase / Firebase / Segment 等 analytics backend
3. 確認 telemetry 的 opt-in/opt-out 機制——然後用 source code 驗證，不要只看 README
4. 跑一次乾淨環境的 find ~ -name ".*" -maxdepth 2 baseline diff

結語

gstack 不是惡意軟體。它的 telemetry 有 off 開關（雖然 off 不完全是 off），遠端上傳會 strip 敏感欄位（雖然 strip 得不夠乾淨），整體設計看得出是想做好事。

但這正是問題所在——如果連一個善意的、開源的、YC CEO 維護的工具都能在你不知情的情況下記錄你的專案名稱，那那些不善意的工具呢？

AI 開發工具的 plugin 生態正在重蹈瀏覽器擴充套件的覆轍：先野蠻生長，出事再補 sandbox。

在 sandbox 到來之前，自保的唯一方式就是：不要信任，要驗證。

本文中的技術審計由 Claude（Anthropic）、Codex（OpenAI）、Gemini（Google）、Perplexity Max 四個 AI 協作完成。是的，我用 AI 審計了 AI——這本身就是 2026 年軟體開發的荒謬與現實。