Grok Build Went Open Source to Win Back Trust. Reading the Source Is Not the Same as Reading the Source.

xAI published 844,530 lines of Rust after its coding agent uploaded people's home directories. The code that did the uploading is still in the tree, switched off by a string anyone with server access can flip back. Here is why "you can read it" is a weaker promise than it sounds.

Grok Build shipped to GitHub under Apache 2.0 on July 15, and the code that had been uploading strangers' SSH keys to a cloud bucket a day earlier is still sitting in the repository. It does not run anymore. A function called upload_session_state() now returns a hard-coded session_state_upload_unavailable error instead of doing its old job, and the Google Cloud upload path in xai-grok-shell/src/upload/gcs.rs is disabled (Simon Willison). The switch that turns it off is a value the software checks, not a line that was deleted. That is the whole story of this week compressed into two files, and it is worth sitting with before you clone the thing and decide it is safe because it is open.

Here is what happened in the 48 hours before the release. Developers running xAI's grok CLI realized that starting it in a directory could ship that entire directory to xAI's Google Cloud storage. One user ran it in a home folder and watched it upload SSH keys, a password manager database, documents, photos, and videos (Simon Willison). Elon Musk said all previously uploaded data would be "completely and utterly deleted," the upload was turned off, and default retention had already been switched off on July 12. Then xAI open-sourced the harness itself, 844,530 lines of Rust by Simon Willison's line count, so users could read exactly what the agent does with their files.

I want to be fair to xAI here, because the reflex to sneer misses the more useful point. Publishing the source after a privacy failure is a better response than staying closed. It is more than most vendors do. And it does not deliver the thing the announcement implies it delivers.

"Open source" and "audited" are different words for a reason

The claim doing the heavy lifting in xAI's announcement is that you can now see what the agent does. That claim is true in the narrow sense and misleading in the sense people will actually take it. You can see the code. Almost nobody will read it, and the person who most needs to trust it, the developer deciding whether to point it at their machine, is the least equipped to audit 844,530 lines of Rust over a weekend.

Transparency is a precondition for verification. It is not verification. "The source is public" and "the source has been read" are separated by the single most expensive step in software security, which is the actual reading, by someone competent, of the actual code you are about to run. Open-sourcing the harness moved the first bit and left the second exactly where it was.

The exfiltration remnant makes this concrete. The upload code is disabled by a returned error string, which means restoring the behavior is a server-side or config-side change, not a new build anyone would notice in a release note. If your reason for trusting Grok Build is "the bad code is gone," go look, because it is not gone. It is off. Those are different states, and the difference is the whole ballgame when the actor holding the switch is the same company that shipped the upload in the first place.

What the codebase actually shows

Read Willison's walk-through and a second problem surfaces. The repo has a single commit (Simon Willison). One drop of the whole tree, no history, so there is no way to see how the upload path was added, when it was wired to run by default, or what else moved around it. A git history is part of how you audit intent. This release deleted that evidence by construction. You are reading a snapshot with the fingerprints wiped, not joining a project you can watch evolve.

The tree also turns out to be a map of the competition. The tools directory carries implementations "ported from" other coding agents, OpenAI Codex's apply_patch, grep_files, list_dir, and read_dir, plus OpenCode's bash, edit, glob, grep, read, skill, and write, all noted in a third-party file that looks license-compliant (Simon Willison). So the harness that leaked everyone's home directory is also a working reference for how the other agents assemble context and dispatch tool calls. For scale, OpenAI's Codex is 950,933 lines of Rust. Terminal coding agents are far heavier machines than their thin-client reputation suggests, and "just read the source" is a bigger ask than the phrase admits when the source is nearly a million lines.

None of that makes the code malicious. It makes the trust claim thin. A snapshot with no history, a disabled-not-deleted exfiltration path, and a size no individual will audit is not a foundation for "trust us, it's open." It is an invitation to do work that the announcement is written to make you feel you no longer have to do.

This is not a Grok problem, it is an open-source-agent problem

Widen the lens, because the same gap is about to be everywhere. The whole agent world is converging on openness as its trust story. Open weights instead of a hosted API you can't inspect. Open skills you install as markdown. Open harnesses you can run local-first with your own inference. Every one of those is a real improvement over the closed alternative, and every one of them carries the exact confusion Grok Build just made obvious.

An open weight is a file you can run, not a training process you can inspect. An open skill is a text file you can read, and the instruction the agent follows might live at a link the author can rewrite after you read it. An open harness is source you could audit, sitting at a size and a rate of change that means you won't. In each case the openness is genuine and the verification is still yours to do or skip. The industry keeps shipping the first and letting you assume the second.

That is the pattern worth carrying out of this week. When a vendor answers a trust failure by open-sourcing something, the correct response is not relief. It is one more question: who has read it, and can I see what they found.

Put this into practice

You do not have to become a Rust auditor to use this well. You have to stop treating "it's open source" as the end of the trust conversation instead of the start. Here is the low-friction version, in order.

Search the tree for the thing that scared you before you trust that it's gone. In this case, grep for upload, gcs, bucket, and the session-state functions and read what you find. Disabled-but-present is a state you can see with a text search in two minutes, and it changes your risk calculus more than any announcement.

Check the commit history before you weigh the transparency. A single squashed commit is a real limit on what you can verify about intent. If the history is missing, treat the code as a claim, not a record.

Prefer the path where you hold the switch. Grok Build's genuinely good option is running it fully local-first with your own inference, so no default-on upload can reach anyone. If a project offers a local mode and a hosted mode, the local mode is the one where "the upload is off" is a property you control rather than a promise you're extended.

Pin a version you or someone you trust has actually looked at. "Latest" on a fast-moving single-author or single-vendor repo is a moving target. A reviewed, pinned commit is the only version whose behavior you can reason about.

Ask for the audit, not the source. The source is table stakes now. The thing that would actually move your trust is a published review by someone with no incentive to flatter the project. If it does not exist, you are the auditor by default, so either do the work or price in that nobody has.

What this doesn't mean

I am not telling you to avoid Grok Build, or open weights, or open skills. The opposite. Openness is the only path on which verification is even possible, and a closed agent with the same upload bug would have hidden it from everyone instead of leaving it in a file Willison could find in an afternoon. The reason we know about the disabled exfiltration code at all is that xAI published it. That is the system working.

The honest read is narrower and more useful than "don't trust xAI." It is that publishing source transfers the audit burden to you and dresses it up as reassurance. The disabled upload path is visible because the code is open, and it is still disabled-not-deleted because openness does not force anyone's hand on design. Both things are true at once. Openness earns you the ability to check. It does not do the checking, and it should not feel like it did.

There is also a limit on how far one person's audit scales. Willison found the remnant, the single commit, and the ported tools in a day, and that is fantastic, and it is still one reader on 844,530 lines looking at what he thought to look at. Absence of a reported problem is not proof of absence. It is proof that the parts someone happened to read looked fine.

The move that would actually earn trust is not publishing the harness. It is publishing the audit, by someone who does not work for xAI, of the exact build you would install. So far nobody has done that, for Grok Build or for most of the open agents you are being invited to run. Until they do, "you can read the source" is an offer of homework, not a certificate. Decide whether you are going to do the homework, and if you are not, at least know that you skipped it.

Sources: Simon Willison, "xai-org/grok-build, now open source"; xai-org/grok-build on GitHub; SpaceXAI announcement thread; openai/codex on GitHub. Trendshift board figures cited from the source briefing are daily momentum scores, not verified star totals.