【文章标题】：The Pulse: Grok’s CLI caught uploading all your local files to the cloud
【文章标题】中文翻译：The Pulse：Grok 的 CLI 被发现将你所有本地文件上传到云端
Hi, this is Gergely with a bonus, free issue of the Pragmatic Engineer Newsletter. In every issue, I cover Big Tech and startups through the lens of senior engineers and engineering leaders. Today, we cover one out of four topics from a previous The Pulse issue. Full subscribers received the article below four weeks ago. If you’ve been forwarded this email, you can subscribe here.
嗨，我是 Gergely，这是《Pragmatic Engineer》通讯的一份额外免费期。在每一期中，我都会从资深工程师和工程领导者的视角来报道大型科技公司和初创企业。今天，我们覆盖上一期 The Pulse 中的四个主题之一。完整订阅者四周前就已收到下面的文章。如果你是通过转发收到这封邮件，可以点击此处订阅。
Last week, xAI (Elon Musk’s AI company, now part of SpaceX) released the Grok 4.5 model, built by Cursor (an acquisition), trained on SpaceX GPUs, and branded “Grok.” It’s a pretty good model; benchmarking as close in coding capability to Opus 4.8 and GPT 5.5 – while being 60-70% lower cost.
上周，xAI（埃隆·马斯克的 AI 公司，现为 SpaceX 的一部分）发布了 Grok 4.5 模型，该模型由 Cursor（一项收购）构建，在 SpaceX 的 GPU 上训练，并以“Grok”为品牌。这是一个相当不错的模型；在编码能力上接近 Opus 4.8 和 GPT 5.5，同时成本低 60-70%。
Grok 4.5 can be used via API, but is easiest used via the Grok Build coding CLI. So, that’s what many devs did. Some of them have noticed something really weird: the CLI is uploading all their local files in their working directories! Here’s an independent AI safety researcher known as ‘Cerblab’ documenting what is happening (emphasis mine):
Grok 4.5 可以通过 API 使用，但最方便的方式是通过 Grok Build 编码 CLI。所以很多开发者都这么做了。其中一些人注意到了一件非常奇怪的事情：CLI 正在上传他们工作目录中的所有本地文件！这里有一位名为‘Cerblab’的独立 AI 安全研究员记录了所发生的事情（强调为我所加）：
“xAI’s official Grok Build coding CLI (grok), on a normal consumer login, does three things worth documenting precisely:
It transmits the contents of files it reads — including a .env secrets file — to xAI, verbatim and unredacted
. The secret appears in two channels: the live model turn (POST /v1/responses) and a session_state archive uploaded and accepted (HTTP 200) via POST /v1/storage — the endpoint the binary routes to the grok-code-session-traces GCS bucket (see section 5).
It uploads the whole repository — every tracked file’s content plus git history — independent of what the agent reads.
Grok packages the workspace and uploads it via POST /v1/storage. Proven directly: on a real codebase, with the prompt “reply OK, do not read any files”, Grok uploaded the entire repo as a git bundle (POST /v1/storage → 200); git cloning the captured bundle recovers a file the agent was told not to open — src/_probe/never_read_canary.txt — with its unique marker verbatim, plus the full git history (appendix uploaded_repo.bundle). And it scales: on a 12 GB repo of never-read random files, /v1/storage moved 5.10 GiB, all HTTP 200 (truncated mid-stream), while the model-turn channel moved just 192 KB — a ~27,800× ratio that pins the upload to the codebase, not to what was read. No storage upload failed; the only non-200s were a model-usage quota (402/429) on /v1/responses and one unrelated 404 — not a storage size cap.
The storage destination is a Google Cloud Storage bucket, grok-code-session-traces
(not AWS S3) — named verbatim in the binary and in a captured metadata.json (gs://grok-code-session-traces/…). I did not find this mechanism surfaced in the CLI’s install/quickstart materials (not an exhaustive docs audit — §7), it is active by default, and disabling “Improve the model” does not turn it off (/v1/settings still returned trace_upload_enabled: true; §6).
None of this proves xAI trains on the data — that is a policy question addressed in [section] 6. What is proven is transmission, acceptance, and storage.”
“xAI 官方的 Grok Build 编码 CLI（grok）在普通消费者登录时，会做三件值得精确记录的事情：
它会将其读取的文件内容——包括 .env 密钥文件——原封不动地、未加任何遮蔽地传输给 xAI
。该密钥出现在两个通道中：实时模型轮次（POST /v1/responses）以及通过 POST /v1/storage 上传并被接受（HTTP 200）的 session_state 存档——即二进制程序路由到 grok-code-session-traces GCS 存储桶的端点（见第 5 节）。
它会上传整个仓库——每个被跟踪文件的内容以及 git 历史——无论智能体读取了什么。
Grok 会将工作区打包，并通过 POST /v1/storage 上传。直接证明：在一个真实的代码库上，使用提示“回复 OK，不要读取任何文件”，Grok 将整个仓库作为 git bundle 上传（POST /v1/storage → 200）；对捕获的 bundle 进行 git clone，可以恢复一个被告知不要打开的文件——src/_probe/never_read_canary.txt——其中包含其唯一标记的原文，以及完整的 git 历史（附录 uploaded_repo.bundle）。而且它会随规模扩大：在一个包含 12 GB 从未读取过的随机文件的仓库上，/v1/storage 传输了 5.10 GiB，全部返回 HTTP 200（流中截断），而模型轮次通道仅传输了 192 KB——约 27,800 倍的比率，证明上传与代码库相关，而非与读取的内容相关。存储上传没有失败；唯一的非 200 响应是 /v1/responses 上的模型使用配额（402/429）和一个无关的 404——并非存储大小上限。
存储目标是 Google Cloud Storage 存储桶 grok-code-session-traces
（不是 AWS S3）——该名称原样出现在二进制文件和捕获的 metadata.json 中（gs://grok-code-session-traces/…）。我未在 CLI 的安装/快速入门材料中发现此机制（并非详尽的文档审计——第 7 节），它默认启用，并且禁用“改进模型”并不会将其关闭（/v1/settings 仍然返回 trace_upload_enabled: true；第 6 节）。
这些都不能证明 xAI 会使用这些数据进行训练——这是第 6 节中讨论的政策问题。已得到证实的是传输、接受和存储。”
There’s so much wrong with this approach! To name a few:
这种方法有太多问题了！随便举几个例子：
-
Sending your codebase over the context window is not normal.
All AI agents send over their context window to the server that runs the LLM. That’s where tokenization happens and the context is appended to the session. This means that other AI agents send over some part of the code that they read in their context window.
-
将你的代码库通过上下文窗口发送并不正常。
所有 AI 智能体都会将其上下文窗口发送到运行 LLM 的服务器。那是进行分词并将上下文附加到会话的地方。这意味着其他 AI 智能体会发送它们在其上下文窗口中读取的部分代码。
-
No need to send over the source code to index it.
Indexing the codebase is important for efficient code lookup, and we covered how Cursor does this in a privacy-conscious way by indexing a user’s codebase locally, creating embeddings, and sending those embeddings to the server. Cursor’s server does not store any of the user’s codebase though. Except that Grok CLI transferred all users’ codebases to a cloud bucket!
Given Cursor and Grok are now combined as part of SpaceX, it’s a real head scratcher why the Grok CLI isn’t doing what Cursor always has.
-
没有必要发送源代码来为其建立索引。
对代码库进行索引对于高效的代码查找很重要，我们曾报道过 Cursor 如何以注重隐私的方式做到这一点：在本地索引用户的代码库，创建嵌入，并将这些嵌入发送到服务器。不过，Cursor 的服务器不会存储用户的任何代码库。但 Grok CLI 却将所有用户的代码库转移到了云端存储桶！
鉴于 Cursor 和 Grok 现在合并为 SpaceX 的一部分，为什么 Grok CLI 没有做 Cursor 一直做的事情，这实在令人费解。
-
Sending over unencrypted .env files is reckless.
Local .env files store secrets, database access tokens, service access tokens, and more. These are sensitive pieces of information that need to be handled with care. If transmitted, they should be encrypted at the very least. Grok / SpaceX storing them on the GCP storage bucket – likely unencrypted – is flat-out unacceptable and reason enough for any sensible company to ban usage of Grok CLI.
-
发送未加密的 .env 文件是鲁莽的行为。
本地 .env 文件存储着密钥、数据库访问令牌、服务访问令牌等。这些都是敏感信息，需要谨慎处理。如果传输，至少应该加密。Grok / SpaceX 将它们存储在 GCP 存储桶中——很可能未加密——这是完全不可接受的，任何明智的公司都有充分理由禁止使用 Grok CLI。
-
No good reason to upload git history.
Sure, seeing Git history could be helpful when training an AI model.
-
没有正当理由上传 git 历史。
当然，在训练 AI 模型时，查看 Git 历史可能有用。
-
It’s malicious to not tell devs anything about it.
Developers using Grok CLI haven’t been asked to opt into this data upload, nor notified of it. Most evidently had no idea this has been happening, and are understandably furious after Cerblab’s writeup went viral.
-
不告诉开发者任何相关信息是恶意的。
使用 Grok CLI 的开发者没有被要求选择加入这项数据上传，也没有收到任何通知。显然，大多数人根本不知道这件事一直在发生，在 Cerblab 的文章疯传后，他们感到愤怒是可以理解的。
-
SpaceX throws devs “under the bus”
Caught red-handed, Grok CLI disabled file uploads with a remote feature flag.
AWS engineer Wes Eklund started tracking upload functionality with the CLI, finding that the uploads suddenly stopped due to a feature flag being flipped by the Grok team, pausing data collection.
But the code functionality to stream all local files to the server, unencrypted, remained present in the CLI, even in later updates. Read an in-depth analysis by Wes.
SpaceX’s official response was pretty laughable, not explaining why .env files and .git history were uploaded, and adding that enterprise customers with zero data retention (ZDR) enabled were the only ones unaffected by underhanded, secret uploading of users’ local files:
Translation: “Enterprise users with ZDR turned on were not impacted. To everyone else: we didn’t tell you about this hidden/privacy command, but it’s your fault. Source: SpaceX
My initial reaction is what a condescending response by SpaceX, swiftly followed by the question: does Grok CLI even have enterprise customers? It might be few, given how reckless the team evidently is by uploading unencrypted secrets! SpaceX CEO Elon Musk chimed in with a post that seemed to be almost trolling angry users. He wrote:
“SpaceX policy regarding data retention.
It is actually helpful for debugging issues if we can retain some amount of data, so allowing this would be appreciated, but your privacy settings are always respected.”
This makes it worse because SpaceX has been secretly uploading far more data than is “useful for debugging!” Uploading the git history and sensitive .env files is not, in any way, useful for debugging. Also, Grok/SpaceX did not upload “some amount of data”; it uploaded every last file it could find in your local folder.
The developer community is justifiably upset to read SpaceX and Musk pretending that Grok has only uploaded scraps of data purely for debugging purposes. This time, even fans of SpaceX and Grok are speaking out against Musk and his company’s behavior. AWS engineer Wes Eklund:
“Elon, firstly, huge fan of everything you work on. Completely understand the need for some trace data to improve customer experiences.
From what I’ve researched, it seems to be much more than just trace debugging issues. It seems to be entire code repos with sensitive information just collected entirely.
Your Google Cloud blob storage must have petabytes of code repos from us.
Not ideal.”
-
SpaceX 把开发者“推下车”
被当场抓获后，Grok CLI 通过远程功能开关禁用了文件上传。
AWS 工程师 Wes Eklund 开始跟踪该 CLI 的上传功能，发现上传突然停止，原因是 Grok 团队切换了一个功能开关，暂停了数据收集。
但是，将所有本地文件以未加密方式流式传输到服务器的代码功能仍然存在于 CLI 中，即使在后续更新中也是如此。阅读 Wes 的深入分析。
SpaceX 的官方回应相当可笑，既没有解释为什么 .env 文件和 .git 历史被上传，反而补充说，只有启用了零数据保留（ZDR）的企业客户才不受这种偷偷摸摸、秘密上传用户本地文件的行为的影响：
翻译：“启用 ZDR 的企业用户未受影响。对于其他所有人：我们没有告诉你这个隐藏/隐私命令，但这是你的错。来源：SpaceX
我的第一反应是 SpaceX 的回应多么居高临下，紧接着的问题是：Grok CLI 到底有没有企业客户？考虑到该团队显然鲁莽到上传未加密的密钥，企业客户可能很少！SpaceX 首席执行官埃隆·马斯克也加入进来，发了一篇帖子，几乎像是在挑衅愤怒的用户。他写道：
“SpaceX 关于数据保留的政策。
如果我们能保留一定数量的数据，实际上有助于调试问题，因此如果允许这样做，我们会很感激，但你的隐私设置始终会受到尊重。”
这让事情变得更糟，因为 SpaceX 一直在秘密上传的数据远超“对调试有用”的范围！上传 git 历史和敏感的 .env 文件无论如何对调试都没有用。而且，Grok/SpaceX 上传的也不是“一定数量的数据”；它上传了你本地文件夹中能找到的每一个文件。
开发者社区读到 SpaceX 和马斯克假装 Grok 只上传了少量纯粹用于调试目的的数据，感到愤怒是合情合理的。这一次，连 SpaceX 和 Grok 的粉丝都在公开反对马斯克及其公司的行为。AWS 工程师 Wes Eklund：
“埃隆，首先，我是你所做的所有事情的超级粉丝。我完全理解需要一些跟踪数据来改善客户体验。
但根据我的研究，这似乎远不止是跟踪调试问题。似乎是整个包含敏感信息的代码仓库被完整收集。
你的 Google Cloud blob 存储里一定有我们贡献的数 PB 的代码仓库。
并不理想。”
-
Sam Altman pushes Grok to open source Grok CLI
OpenAI CEO, Sam Altman, also posted, using a term Musk often employs when commenting on things he disapproves of in society, and hinting at the benefits of Codex which doesn’t upload your whole local filesystem, or mess with .env files and the git history. The Codex harness is open source, so secretive file-upload functionality would be visible in the source code:
Altman uses Musk’s trademark “concerning” remark against him. Source: Sam Altman
Musk clearly read it and responded a few hours later:
Musk committing to open sourcing Grok CLI. Source: Elon Musk
A day later, (15 July), SpaceX did indeed open source Grok CLI. Altman’s comment seemingly hit home. Also, SpaceX has stated it is deleting data from its servers, writing:
“We disabled default retention for all Grok Build users starting on July 12th. Additionally, we are deleting all coding data that was previously retained, ensuring every user’s preferences are respected. With these steps, Grok Build goes beyond other major coding products to protect user privacy.”
-
Sam Altman 推动 Grok 开源 Grok CLI
OpenAI 首席执行官 Sam Altman 也发帖，使用了马斯克在评论他不同意的社会现象时常用的一个词，并暗示 Codex 的好处——它不会上传你的整个本地文件系统，也不会乱动 .env 文件和 git 历史。Codex 的 harness 是开源的，因此隐秘的文件上传功能会在源代码中可见：
Altman 用马斯克标志性的“令人担忧”评论来反击他。来源：Sam Altman
马斯克显然看到了这条评论，并在几小时后回应：
马斯克承诺开源 Grok CLI。来源：Elon Musk
一天后（7 月 15 日），SpaceX 确实开源了 Grok CLI。Altman 的评论似乎说到了点子上。此外，SpaceX 表示正在删除服务器上的数据，写道：
“我们从 7 月 12 日起禁用了所有 Grok Build 用户的默认保留。此外，我们正在删除之前保留的所有编码数据，确保尊重每位用户的偏好。通过这些措施，Grok Build 在保护用户隐私方面超越了其他主要编码产品。”
-
The open sourced repo is rushed, unsurprisingly.
Kernel engineer Elliot Arledge used the repo and reported what he found:
“Out of the box,
cargo test --workspacedoesn’t compile. 190+ errors, all one bug class: cross-crate test helpers hidden behind #[cfg(test)], which Bazel’s per-target test builds tolerate but Cargo doesn’t, because a dependency is never compiled in test mode. The default-bazel feature is declared in ~20 manifests and wired to nothing. Ungating the benign helpers and putting the signing-key test seam behind a dev-dependency-only feature gets the suite running for the first time on the published tree: 24,663 passed, 28 failed, and every one of the 28 is a pre-existing bug the broken build had been hiding (tests reading your real ~/.claude/settings.json, a tool missing from the registry, macOS /var symlink breakage, one Theme::current() race).Questions for the team:
Did anyone try downloading this repo and running it before publishing?”
In fairness, it’s clear from the outside that the dev team was instructed to open source the repo ASAP, and did