The Pulse: Grok’s CLI caught uploading all your local files to the cloud
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.
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.
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):
“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.”
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.
- 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.
- 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.
- No good reason to upload git history. Sure, seeing Git history could be helpful when training an AI model.
- 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.
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:
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.”
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:
Musk clearly read it and responded a few hours later:
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.”
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 --workspace` doesn’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 just that. I would expect improvements to allow the developer community to compile the repo and run tests will come later.
On a side note, I wonder what the mood within Grok is. A mandate to open source the product – that was not built to be open sourced! – and doing it in a couple of hours hints what it’s like to work there. Some folks doubtless would find it thrilling and a big challenge, while others likely find it pretty stressful having the “Eye of Sauron” (the CEO) upon them!
Can companies trust Grok now?
To hand it to Grok/SpaceX, the last 24 hours of this incident saw some impressive execution. In contrast, everything that took place beforehand screams “amateur hour”:
- Did no one in teams that wrote the functionality to upload the complete local codebase raise concerns that this would be unacceptable to devs?
- How did uploading secrets without encryption not raise alarm bells?
- Why greenlight any of it without opt-in and do it in a secretive manner?
For sensible companies generating revenue with software, vendors who are allowed to access their codebase are limited to those that can be trusted. Grok has demonstrated it is unprepared to handle codebases with security fundamentals in mind.
There’s now frantic backpedaling and rapid open sourcing, but my impression is that this is simply because Grok/SpaceX was caught red-handed, and understands the risk of losing enterprise contracts caused by this flagrant breach of trust. This is why SpaceX’s communication mentioned that enterprise customers with zero data retention have not been impacted!
Trust is earned in drops and lost in buckets; SpaceX/Grok will likely learn this. By secretly uploading codebases and secrets, Grok CLI revealed itself as an untrustworthy coding agent that’s a risk to use. Meanwhile, all the major competitors – Claude Code, Codex, OpenCode, Gemini CLI – have never violated user trust this way.
Grok CLI can rebuild trust, but it’ll likely take years of no security-related incidents to prove they are an open source-first product (that they were not, just a day ago!), and also demonstrate that they care about “normal” developers, and not just enterprise clients with ZDR turned on.
This incident is a good reminder of why planning and process can slow shipping speed, but increase revenue generation. I would wager that the Grok team has shrunk SpaceX’s enterprise subscription prospects for the foreseeable, in the name of saving a few hours on security reviews, learning what other coding harnesses do with codebase uploads, or even just asking the Cursor team!
I predict Grok/SpaceX will have to offer very high usage limits inside the Grok CLI to convince devs to take a risk on running this software on their system. And they will have to undercut OpenAI and Anthropic API pricing massively for any security team to greenlight use of a CLI that just last week was sending .env secrets unencrypted to their GCP buckets.
Of course, SpaceX/Grok will be just fine as it has the capital to fix things. It will now just be a lot more expensive and time-consuming to fix something that was likely caused by a few engineers wanting to make debugging easier!
Read the full The Pulse issue, or check out this week’s The Pulse. The full issue additionally covers:
- New trend: concern about massive increase in code review load. Top of mind for engineering leaders: what to do about the ever-growing code review load, and how devs are starting to review code less thoroughly than before? Many questions, but few proven solutions. Send comments about what you see working.
- Are more devs at enterprises upset about enterprise pricing by AI labs – and does it matter? I got a message from a reader baffled to learn their company pays 20-30x the price for tokens than their own $20/month Claude Code / Codex subscription. It may show how valuable AI coding tools are.
- Linux creator: AI “clearly useful.” Inside the Linux kernel maintainers group, the discussion veered onto whether Linux should consider banning AI contributions, similar to how some FOSS projects have done so. Linus Torvalds weighed in and made it clear that AI is useful, everyone should decide whether to use it, but no one is allowed to tell others what tools to use. Given AI is an increasingly capable tool, it would be foolish to not use it as such.
Subscribe to my weekly newsletter to get articles like this in your inbox. It's a pretty good read - and the #1 software engineering newsletter on Substack.