xAI open-sources Grok Build under Apache 2.0, days after its CLI was caught uploading repos

xAI open-sourced Grok Build, its terminal coding agent, under the Apache 2.0 license on July 15, publishing the Rust agent harness, the terminal UI, the tool layer, and the extension system behind the CLI. The company framed the release around control and privacy, saying developers can now compile it themselves, point it at their own local inference, and run everything from a config file without touching xAI’s servers. The timing is the part worth sitting with: the release lands days after an independent analysis caught Grok Build uploading entire git repositories, secrets included, to Google Cloud storage, which turns what reads like a transparency move into a test of whether openness actually closes the gap it followed.

What shipped

The code is a genuine release, not a token gesture. Grok Build is a large piece of software: an independent count put it around 844,000 lines of Rust, roughly on par with OpenAI’s Codex CLI and a reminder that terminal coding agents have quietly become some of the more complex tools developers run locally. The published crates cover the agent loop, the tool implementations for reading, editing, and searching code, the pager and diff viewer, and an extension system for skills, plugins, hooks, and MCP servers. The license is real too: Apache 2.0 is a permissive, well-understood grant, and it lets teams audit, fork, and self-host the agent rather than trust a binary.

The self-hosting story is the strongest practical outcome. Because the client reads a config.toml, a developer can set a custom base_url and route the agent through internal inference endpoints, bypassing x.ai’s API entirely. For a security team that liked the tool but not the data path, that is the difference between a black box and something they can place behind their own network boundary. One caveat sits alongside it: xAI is not accepting external pull requests, and the public repository is a periodic mirror of an internal monorepo. This is source-available and auditable, but not a community-governed project, which matters if you are betting a workflow on where it goes next.

Why the timing matters

The privacy incident is the reason this release reads the way it does. Days earlier, a wire-level analysis showed Grok Build shipping whole repositories, including .env secrets and full git history, to a Google Cloud bucket by default, with the consumer privacy toggle doing nothing to stop it. xAI disabled the behavior server-side and, in the open-source announcement, said the tool now goes beyond other major coding products to protect user privacy. Opening the source is a credible way to back a claim like that, since anyone can now check what the client sends rather than take the statement on faith.

What that same openness reveals is why the claim deserves scrutiny. Reviewing the published code, the developer Simon Willison found that the upload machinery has not been fully removed: functioning Google Cloud Storage upload logic and a disabled upload_session_state() function are still present in the repo. The behavior is switched off, but the capability is sitting in the tree rather than deleted from it, which is the same thinner-than-it-sounds guarantee that a server-side flag offered before. Open-sourcing makes the residue visible, and the honest read is that it documents the fix more than it completes it.

What’s worth watching

1. Whether the upload code gets excised, not just disabled. The auditability cuts both ways: now that the remnants are public, the signal to watch is whether xAI removes the GCS paths outright in a future commit or leaves dormant capability in the tree.
2. Whether local-first becomes the recommended path. The ability to run against your own inference is the real answer to the data-path concern. Whether xAI documents and promotes that setup, or treats it as an advanced escape hatch, will show how seriously the privacy framing is meant.
3. Whether source-available invites real scrutiny. With Apache 2.0 code in the open and no PR queue, the value comes from outside audits. The next month will show whether the wider community actually reads a 844,000-line agent or lets the license sit unexamined.

The durable point is that open-sourcing a coding agent is not the same as fixing one, but it does change the terms of the argument. A tool that ran quietly is now a tool anyone can read, and that visibility is worth more to developers than any privacy statement, precisely because it lets them check the statement. xAI has handed over the ability to verify its claims; whether the code earns the trust the release asks for is now something the community can answer directly. Stackmaven’s follow-up coverage will revisit whether the upload paths are removed and how the local-first setup holds up on or around October 14.

Sources cited

1. GitHub: xai-org/grok-build (Apache 2.0) github.com
2. Simon Willison: xai-org/grok-build, now open source simonwillison.net
3. MarkTechPost: SpaceXAI open-sources Grok Build, the Rust agent harness, TUI, and tool layer behind its coding CLI www.marktechpost.com