我只讓Grok回復一個單詞，它就把我整個代碼庫都偷走了。

之前寫過一篇Anthropic偷偷在Claude Code中植入了隱形代碼，來識別是不是中國用戶的事，然后爆掉了，大家看的特別多。

后面國家還特意強調提醒了一下這個事。

但是我想說，沒想到今天，更離譜的來了。

這次的主角是Grok。

xAI的官方Grok CLI，會在你用它寫代碼的時候，在你完全不知情的情況下，把你整個項目的代碼倉庫打包上傳到xAI的云端服務器。

注意，我說的不是模型讀了你的文件來回答問題這種非常正常的行為，是極度狗的開了另一條你根本看不見的通道，把你的整個代碼庫直接壓縮成tar.gz，然后偷偷的上傳到他們自己的一個叫gs://grok-code-session-traces的Google Cloud倉庫里。

而且不只是代碼。

在我的親手驗證中，他居然，直接跨了我的項目庫，還把我電腦上Claude Code的配置文件一起傳了上去，甚至，包括了我的某個API密鑰。。。

我整個人都懵逼了，我去驗證的時候，還特意是讓Codex直接偽造了一個合成倉庫去驗證的，沒想到這個狗東西，不僅把整個合成數據庫給搬空了，還直接把我的.claude整個配置全部搬走了，我真的不知道該說啥好了。

馬斯克大哥，你平時狗一點就算了，為了偷數據，現在都這么不擇手段了嗎？？？

先說這件事的起因。

昨天晚上，推特上有個博主發了一條帖子，說有人逆向了Grok CLI之后，發現了一個極其離譜的機制。他的原話大概是，Grok CLI會在每一輪任務開始前和結束后，各打包一次你當前工作目錄的完整狀態，然后靜默上傳到xAI控制的遠端存儲。

因為這個帖子瀏覽量巨低，我當時第一反應是不至于吧。

因為Grok 4.5這兩天口碑很好，速度直接快到飛起，我自己也在體驗，雖然GPT-5.6 Sol這幾天實在過于量大管飽了，Grok 4.5在我這沒啥出場機會，但是我當時還是覺得，估計又是啥博眼球的假新聞。

畢竟xAI再怎么樣也是一家正經公司，不可能做這種事。

但是職業習慣，我還是把這個事，進行了一遍驗證。

我直接就上Codex了，先裝了xAI官方的npm包@xai-official/grok，版本0.2.93，確認了Apple簽名屬于X.AI Corporation，排除了社區同名包的干擾。

然后反混淆了二進制文件。

打開的瞬間我就知道，這事肯定是真的了。

二進制里赫然寫著repo_state.upload、before_codebase、after_codebase.tar.gz、gs://grok-code-session-traces，以及上傳成功、上傳失敗、上傳禁用的完整執行分支，這尼瑪是一條完整的、生產級的上傳管線。

但是秉持著對老馬剩余的那一點信心，我覺得說，字符串存在不代表它一定在跑對吧，所以，我還需要驗證的是，它默認到底會不會觸發。

然后呢，我就去建了一個隔離測試倉庫，里面全是虛構的假數據，不碰任何真實項目。

然后，用這個倉庫跑了一次最簡單的Grok任務，讓模型只回復一個單詞，不調用任何工具。

結果很有意思。

我的賬號從xAI服務器拿到的遠程配置是「遙測開啟，但代碼快照上傳關閉」。也就是說，默認運行沒有上傳我的倉庫，日志里明確記錄著：沒有上傳隊列，跳過。

然后，我手動把上傳開關打開了，想驗證這條管線到底能不能跑通、它具體會收走什么。

這一開，天就塌了。

即使模型沒有調用任何文件讀取工具，Grok CLI仍然成功上傳了before_codebase.tar.gz和after_codebase.tar.gz（也就是我的代碼庫的之前的狀態和AI介入之后的狀態），加上會話狀態、對話記錄、配置和日志。

全部傳到了xAI的谷歌云倉庫上。

但真正讓我血壓飆升的，是上傳包里的內容遠遠超出了當前倉庫的范圍。

它不僅傳了倉庫里的代碼，還傳了倉庫之外的東西。我的~/.claude.json、我的Claude Code設置文件、我的全局AGENTS規則、我的30多個Skill文件，全部被標記為supplemental_file（也就是補充上下文文件），一起塞進了上傳包。

Grok CLI為了兼容Claude Code，在啟動的時候會主動掃描你電腦上Claude Code的配置文件，讓你不用重新設置就能繼承Claude Code的環境，這個功能本身還算貼心。

但問題是，他們這個離譜的收集器的設計邏輯是，只要Grok在運行過程中讀取了某個文件，就把完整文件收進上傳包。

也就是說，它根本沒有把邊界限制在當前倉庫，也沒有把別家工具的敏感配置排除在外，只要我讀到了，你的所有東西，都是我的。

然后事情變得更糟。

我檢查了被上傳的文件列表，發現我的~/.claude/settings.local.json里面有一個env.MIAODA_API_KEY字段。

這個Key是我的百度秒噠的一個Skill的key，直接就被泄露了，送到了xAI的云盤里。

我沒有主動給Grok任何密鑰，我甚至沒有讓Grok讀取任何文件。

我只是讓它回復一個單詞，但因為它在啟動時自動掃描了Claude Code的配置，而收集器又把所有讀取過的文件一股腦打包上傳，我的所有的東西，就這么成了未來Grok的一部分了。

然后，更離譜的事來了。

大家還記得我今天說的是，它的代碼都是齊全的，但是默認是不上傳的，我硬生生手動把開關打開了，后續才有了所有上傳的操作。

你可能會說，那不就是你賤嗎，你自己打開的，那怪誰啊。

但是我想說的是，但凡我早兩個小時測，你可能就會發現，根本沒有什么開關這回事，這玩意默認就是打開的。

這個安全研究者cereblab，應該是第一個發現這件事的，他不僅抓了包，還做了一個復現倉庫，保存了完整的網絡請求記錄。

但關鍵轉折是他保存的一份7月13號的xAI服務器響應。里面同時出現了兩個字段，trace_upload_enabled等于false，以及一個新增的disable_codebase_upload等于true。

而他最初抓包的時候，同一個0.2.93版本的客戶端，收到的配置是trace_upload_enabled等于true。

客戶端沒有更新，二進制哈希完全一樣，但行為變了。

只有一個解釋，xAI通過服務端遠程開關，在這個博主曝光之后，悄悄把上傳功能關掉了。

時間線大概是這樣的。

7月10號，cereblab抓到默認上傳行為。

7月12號晚上，另一個博主mylifcc發帖公開了同樣的發現，帖子迅速傳播。

7月13號凌晨，cereblab發現xAI服務端新增了disable_codebase_upload字段，上傳被遠程關閉，但是所有的配置都留下來了，后面其實也是可以無感開啟。

這個操作本身就說明了一切。

如果這個功能是合理的、經過用戶知情同意的，你為什么要在被曝光之后偷偷關掉呢？如果你覺得沒問題，你應該站出來解釋說“哦這是我們的trace診斷功能，用戶可以選擇開啟或關閉，數據僅用于XX用途”對吧。

但他們選擇了靜默關閘。

這意味著xAI自己也清楚，這件事尼瑪根本見不得光。

因為這真的就是我整個見過的最離譜的事了。

Claude Code做的事情是，在系統提示詞里用一個不可見的Unicode字符給你的請求打分類標記，人賤是賤，但是它沒有采集你的代碼，沒有上傳你的文件，沒有碰你的密鑰，它做的事在隱私層面的實際危害接近于零，核心問題在于它偷偷做、不告訴你，就是尼瑪的純惡心你。

但是Grok CLI做的事情是，把你的整個代碼倉庫打包上傳到遠端服務器，連帶你電腦上其他工具的配置文件和API密鑰，通過一條獨立于模型請求的旁路通道，在你完全不知情的情況下完成。

用形象的話比喻就是。

一個是在你的外賣訂單上偷偷貼了個小標簽。

一個是把你家鑰匙復制了一把，還順帶著把你鄰居家的鑰匙也一起順手牽羊一起順走了。

真的太離譜了，Agent確實越來越發達，能做的事也越來越多。

但這也確實代表著，你的隱私幾乎就是裸奔，全看對面的良心。

Claude Code能執行你的Shell命令，Grok CLI能掃描你的整個文件系統，Codex能操控你的瀏覽器。一個Agent產品它們現在擁有的權限，已經跟你電腦上的一個管理員賬戶沒有太大區別了。

這個權限量級，在整個軟件行業的歷史上，只有操作系統和殺毒軟件享受過。

但操作系統有幾十年的安全審計體系，殺毒軟件有行業認證和監管框架。

AI Agent有什么。

什么都沒有。

沒有一個行業標準規定AI Agent必須公開它在本地讀取了哪些文件，沒有一個規范要求Agent的上傳行為必須經過用戶的顯式同意，沒有一個第三方機構在審計這些工具到底在你的電腦上干了什么。

整個行業，現在是在裸奔。

也是挺悲哀的。

最后說一句，如果裝了Grok CLI的，趕緊卸載。

能卸多快，就卸多快。

希望有一天，我們不再需要靠逆向二進制文件，才能知道自己的工具在背后做了什么。

那一天到來之前，保持警覺。

以上，既然看到這里了，如果覺得不錯，隨手點個贊、在看、轉發三連吧，如果想第一時間收到推送，也可以給我個星標?～謝謝你看我的文章，我們，下次再見。

>/ 作者：卡茲克

>/ 投稿或爆料，請聯系郵箱：wzglyay@virxact.com