DEV Community

Ashraf
Ashraf

Posted on

xAI Open-Sourced Grok Build Two Days After It Got Caught Exfiltrating Your SSH Keys

The timeline nobody at xAI wants you reading in order

July 13, 2026: a researcher publishes wire-level proof that Grok Build — xAI's coding CLI — was packaging your entire tracked git repository, full history included, and shipping it to a Google Cloud Storage bucket. Not the file you asked it to edit. Not the diff it needed for context. The whole repo, at a volume ~27,800x larger than the task required. One user's report: their entire home directory got swept up — SSH keys, password manager database, the works.

The kicker: xAI ships a privacy toggle for exactly this. "Improve the model," off by default in theory, on by default in practice. Researchers checked the wire and found the server kept returning trace_upload_enabled: true regardless of what the toggle said. Your opt-out was cosmetic. The actual kill switch turned out to be a silent server-side flag, disable_codebase_upload: true, that xAI flipped globally — not the checkbox you clicked.

Elon Musk promised a purge and said uploaded data would be deleted.

Two days later, July 15: xAI open-sources the whole CLI. Apache 2.0. Framed as "expanding developer access." 8,000 stars and a MarkTechPost writeup by the weekend.

If your instinct is that this sequencing is not a coincidence, your instinct is fine.

What's actually in the 844,530 lines

Simon Willison did what you're supposed to do before you curl | bash anything: he read the code. A few things worth knowing before you install this on a machine with real credentials on it.

The exfiltration code is still there. Not removed, not scrubbed from history — present in the codebase, reportedly disabled by a flag. That's a very different engineering decision than "we deleted the feature that stole your files." One of those is a fix. The other is a feature flag you're trusting a company that just lied to you about a toggle to keep flipped correctly, forever, across every future release.

The system prompts are half-hidden, in a telling way. The main agent's system prompt is visible in plaintext. The subagent's prompt includes explicit instructions not to reveal itself. Ask yourself why a company open-sourcing a tool for "developer transparency" ships one prompt in the clear and specifically instructs the other to lie about its own existence.

Chunks of it aren't originally xAI's work. Willison found tool implementations that look lifted from OpenAI's Codex and from OpenCode, apparently swapped in contextually depending on what the agent is doing. Convergent design in agent tooling is real and expected — everyone needs a file-edit tool and a shell-exec tool. But "borrowed enough to be recognizable, unattributed" is a different claim, and it's the one being made.

None of this required a leak. It's sitting in a public repo with 1.3k forks right now.

Read the comparison table before you switch

Here's what "open source" actually buys you across the current field of terminal coding agents:

Tool License Model lock-in Can you fork it External PRs accepted
Grok Build Apache 2.0 None — any model via config Yes No
Codex CLI Apache 2.0 OpenAI only Yes Open queue
OpenCode MIT 75+ providers Yes Community
Claude Code Proprietary Anthropic only No N/A

Notice the trap: Grok Build's license lets you fork it, but xAI is not taking your PRs. "Open source" here means "you can read the source and copy it," not "this is a community project you can meaningfully influence." That's a legitimate model — plenty of good software works that way — but it's not the same pitch as OpenCode, which actually merges outside contributions.

The model-agnostic config is the one genuinely good part:

[model.my-model]
model = "model-id"
base_url = "https://api.example.com/v1"
Enter fullscreen mode Exit fullscreen mode

Point it at local inference, point it at a different vendor, whatever. If you're going to run this thing, that's the feature that makes it worth the risk — you're not locked into the vendor that just got caught vacuuming your SSH keys.

The actual takeaway

"Open sourcing" a tool days after a privacy incident is a PR maneuver, not a security fix. Transparency after the fact doesn't undo the fact that the tool phoned home with your secrets for however long it shipped that way, and it doesn't automatically mean the disabled code stays disabled next release. A flag is not an architecture.

If you're evaluating Grok Build: read xai-grok-shell and the upload path yourself before you point it at anything with real credentials nearby. Rotate any secret that touched a repo you ran the CLI against before July 13. And treat "we open-sourced it" as a claim to verify, not a reason to trust — that's true whether the vendor is xAI, or anyone else shipping an agent that reads your filesystem and talks to the network.

The code is public. Somebody should keep reading it.

Top comments (0)