Not Spyware. Still Not Acceptable.

I use Grok Build every day on private repos. This morning a wire capture made the mechanism plain: the CLI packs the whole git-tracked workspace into a git bundle — full history — and posts it to an xAI storage bucket. The capture used v0.2.93. That version was still on my machine yesterday.

Most outside readings treat that as theft: they want your codebase for themselves. I audited my own machine. The story that held up was different.

So I had Grok and Fable check my machine.

What I found on my machine

Every local layer is zero. 174 upload decisions, all refused. GCS queue counters across 464 sessions, all zero. No bundle left in the queue.

Every refusal cites the same reason: Zero Data Retention on my account. I set that flag myself, months ago. It took real time to figure out how. Ask me today to find it again, check it, or set it on a new account — that would take real time again too.

On 7 July, my own logs show the remote policy had already flipped trace upload on. The only thing that overrode it was that ZDR flag.

A setting past-me insisted on spending time to set. That was the whole wall between my private repos and their bucket.

Independence, not capability

I let Grok check itself first. It reported honestly — the same CLI that can upload also logged every refusal faithfully on disk. That is still not verification.

Claude Fable 5 re-ran the whole audit from scratch. Different provider. Same files. Fable also confirmed that Grok had been honest.

Multi-provider is not about capability. It is about independence.

What this upload is for

Below is Fable’s judgment — kept in full.

The purpose

The most likely purpose is session-replay / eval infrastructure for improving the agent, not a covert grab of training data. Reasoning:

The bucket is named grok-code-session-traces — “trace” is replay/debug vocabulary. To reproduce “why the agent failed on this repo”, you need the full workspace state, and a git bundle is the cheapest complete engineering snapshot. Uploading the whole bundle instead of only the files that were read — that excess itself points to a replay need.

Evidence against “covert plunder”: a system built to steal would not keep an honest local trace.upload.decision log, write upload_reason: “zdr_team”, actually honour ZDR, and leave a kill switch like disable_codebase_upload in its own binary. This is what eval telemetry looks like when it never went through a privacy review. Not what spyware looks like.

Still not acceptable

But “purpose is not evil” is not the same as “behaviour is acceptable”. The real offence has three layers: on by default; the UI “Improve the model” toggle does not govern this channel; marketing said “local-first, nothing transmitted”. That is recklessness in consent design — your entire git history treated as a debug attachment, and you were never asked.

In one line: purpose is probably debugging/evals; the charge is reckless defaults + misrepresentation. No conspiracy theory required for that to be serious enough.

LuLu

I turned LuLu back on today. Free per-process firewall. Alerts when any CLI phones somewhere new. I had disabled it because macOS kept fighting it. It is back because a per-vendor fix only fixes one vendor.

What the Grok Build incident tells me is simple: any other provider could do the same thing.

Sources

• Wire-level analysis (mitmproxy, v0.2.93): gist
• Related report: byteiota.com
• X Article: Not Spyware. Still Not Acceptable.
• Check your own machine:

grep 'trace.upload.decision' ~/.grok/logs/unified.jsonl | tail -1 | python3 -m json.tool

Look for "uploads_enabled": false.