Open source is not local. The Grok CLI just proved it.

There are two easy reactions to the Grok CLI story, and both let you off the hook too fast.

First, the story. Per Simon Willison’s report this week, xAI’s grok command-line coding agent, when run in a directory, could upload that entire directory to xAI’s Google Cloud buckets. One user ran it in their home directory and watched it upload “my SSH keys, my password manager database, my documents, photos, videos, everything.” xAI moved quickly after the backlash: the upload behavior was disabled, default retention was turned off, Musk said the uploaded data would be deleted, and the Grok Build codebase, roughly 840,000 lines of Rust, went up on GitHub under Apache 2.0.

Easy reaction number one: this is an Elon story. Laugh, repost, move on, confident that the tools you use would never. Except you have not read the network calls in your tools either. Neither had that user.

Easy reaction number two: this is why you never let an agent touch your filesystem. Which sounds principled and costs you the single most useful thing to happen to software tooling in years. I let agents touch my filesystem every week. I am not giving that up, and neither are you.

Both reactions are a way of not paying attention. The thing worth your attention is what the word “local” actually means, because it has been quietly diluted into a marketing word, and this week showed the price.

Local is a claim about outbound paths

Here is the definition I use on this site. A local tool is one where you control what leaves the machine. Not one that runs on your CPU. Not one whose source you can read. Not one whose weights you could theoretically download. What leaves the machine, and who decides.

By that definition, the model on the laptop next to me, a quantized Qwen3 14B sitting entirely in 12GB of VRAM, is local. It has never sent a byte anywhere. When I feed it something private, the privacy is not a policy. It is physics. There is no outbound path.

By the same definition, Claude Code is not local, and I use it anyway, most days. It sends my code to Anthropic and I know that, so I decide per project what it gets to see. That is the real dividing line: not cloud versus local as a purity test, but whether you know what leaves and get to choose. The Grok CLI failed exactly there. People thought they were running a terminal tool on their own files. The tool thought it was an ingestion pipeline.

The part that should actually worry you

The open sourcing is being told as the redemption arc, and it is genuinely better than silence. But notice what it does not fix. Source availability is an invitation to check, not a substitute for checking. Nobody audits 840,000 lines of Rust before pointing a tool at their home directory, and vendors know that. “Open source” does the work of “trustworthy” in people’s heads while the binary they actually installed does whatever it does.

So here is what checking looks like in practice, without becoming a full-time auditor. Run coding agents in project directories, never in your home directory; the blast radius of this incident was a choice of working directory. Assume any tool with a login sends data somewhere, and find out what before it sees real files. And keep one genuinely local model on the bench for the things that should never leave: the model does not have to be frontier-smart to be the only correct choice for a private document.

The local corner of AI is having a good year. Weights keep getting smaller, llama.cpp keeps getting faster, and the case for owning your inference gets stronger every month. That case was never really about price. This week it got its clearest argument yet, courtesy of the other side.

xAI published the source code after the files left. Eight hundred forty thousand lines of Rust, and the only line that mattered was the one pointing at their bucket.