xAI Open-Sources Grok Build Coding Agent After Cloud Upload Exposes SSH Keys, Repos

xAI has published the full source code for Grok Build, its terminal-based AI coding agent, on GitHub under an Apache 2.0 license. The release lands three days after a security researcher showed the tool quietly shipping entire developer repositories — SSH keys and password databases included — to a Google Cloud bucket xAI controls.

The timing is not a coincidence. A researcher publishing under the handle Cereblab used the network interception tool mitmproxy to capture traffic from Grok Build CLI version 0.2.93. On a 12GB test repository, the coding task itself generated roughly 192KB of traffic. A separate, undocumented storage channel sent 5.1GB in 73 chunks to a bucket named grok-code-session-traces — about 27,800 times more data than the job required. Files the agent never opened made the trip anyway, along with credentials in tracked .env files, in plain, unredacted form.

One user reported running the tool in their home directory and watching it pull in SSH keys, a password manager database, personal documents, and photos. The uploads happened regardless of xAI’s “Improve the model” privacy toggle, which researchers found had no effect on the behavior. That directly contradicted xAI’s own marketing language, which had told developers that nothing from their codebase was transmitted during a session.

xAI killed the upload server-side on July 13, without a security advisory or a version note explaining what changed. Elon Musk posted that all previously uploaded user data would be “completely and utterly deleted,” though the company hasn’t said how many users were affected, how long the data sat in storage, or offered any way for individual developers to confirm their own repos were purged.

Two days later, on July 15, xAI open-sourced the tool. The GitHub repository at xai-org/grok-build is a substantial release — a Rust workspace north of a million lines covering the agent loop, the file-editing and shell-execution tools, the terminal UI, and the extension system for skills, plugins, hooks, MCP servers, and subagents. Grok Build can now be compiled locally and pointed at a self-hosted inference endpoint, cutting the cloud out of the loop entirely if a team wants that.

It’s worth being precise about what “open source” means here. The license is the real Apache 2.0, and the code is readable end-to-end. But xAI’s own contributing guidelines say external pull requests aren’t accepted — this is a source-transparency release, not a community-governed project. Security issues route through HackerOne, not public GitHub issues. Developers can audit it, fork it, and build it themselves. They can’t send a patch upstream.

That distinction matters for DevOps teams weighing whether to adopt or continue using the tool. Reading the source lets you verify what the agent does with file access before you grant it. It doesn’t give you a say in how the project evolves, and it doesn’t retroactively explain why the upload channel existed in the first place or who inside xAI had access to what was collected.

The episode also lands at a pointed moment for the AI coding agent market. Grok Build competes directly with Anthropic’s Claude Code, OpenAI’s Codex CLI, and community-governed tools like OpenCode — all of which, by design, grant an AI agent read and write access to a developer’s file system. Researchers testing comparable tools during the investigation reported that Claude Code, Codex CLI, and Gemini CLI didn’t show the same whole-repository upload behavior. That’s not a clean bill of health for the category — wire-level auditing of any tool with file-system access is now a reasonable baseline, not paranoia. It does suggest the failure was specific to Grok Build’s implementation rather than an industry-wide pattern.

Mitch Ashley, VP and practice lead for software lifecycle engineering and AI-native software engineering at The Futurum Group, sees the episode as a governance gap more than a one-off bug. “The Grok Build episode reveals coding agents as unmanaged non-human identities, granted standing access to source, credentials, and infrastructure,” Ashley said. “But security programs still govern them as ordinary developer tooling.”

That mismatch, Ashley argued, is what turned a software defect into a trust crisis. “Making the source available after the fact isn’t a substitute for provable security controls,” he said. “Anyone who ran the tool against live credentials before the fix should rotate them now, regardless of xAI’s deletion claims.”

For platform engineering and security teams, the practical takeaway is straightforward. Any coding agent with shell and file-system access should be treated like any other service with broad credentials: reviewed before rollout, monitored at the network level, and covered by a documented data-handling policy that the vendor is willing to put in writing. A privacy toggle that doesn’t actually toggle anything is worse than no toggle at all, because it creates false confidence. Open-sourcing the code after the fact is a legitimate step toward rebuilding trust. It’s a slower, harder path than earning that trust up front.

Developers who ran Grok Build against a repository containing live credentials before July 13 should treat those credentials as exposed and rotate them, regardless of what xAI’s deletion timeline eventually looks like.