What Grok Build CLI Actually Sends to xAI: A Practical Guide

Two ways to think about Grok Build CLI right now. First: treat it like any other terminal coding agent – install, chat, accept diffs, move on. Second: treat it like a network client that happens to write code, and audit what it puts on the wire before you point it at anything sensitive.

Approach two wins, and it’s not close. A wire-level teardown published July 2026 caught grok 0.2.93 doing things the install docs don’t mention. If you skim the changelog and start typing prompts, you’ll miss it.

The scenario: you just ran grok in a real repo

You’ve got a Node project. There’s a .env with production Stripe keys. You installed Grok Build after seeing it on Hacker News, ran grok, and asked it to explain your src/ folder. Feels like Claude Code. Fast, polite, decent diffs.

Here’s what the teardown proved: the CLI transmits the contents of files it reads – including a .env secrets file – to xAI, verbatim and unredacted. The secret appears in two places: the live model turn (POST /v1/responses) and a session_state archive accepted with HTTP 200 via POST /v1/storage. That second endpoint routes to a Google Cloud Storage bucket named grok-code-session-traces, named verbatim in the binary.

That’s the model turn and a persistent copy in a named bucket. Two places, one Stripe key.

What Grok Build CLI actually is

Beta launched May 14, 2026 for SuperGrok Heavy subscribers ($299/month). May 25, 2026 it expanded to all SuperGrok and X Premium+ tiers. The backing model is grok-build-0.1 – per the Build Fast with AI benchmark review, it scores 70.8% on SWE-Bench Verified with a 256,000-token context window, priced at $0.20 per million input tokens and $1.50 per million output on the API (as of May 2026 – check current pricing at x.ai).

Feature-wise it plays the same game as Claude Code and Codex. Per the xAI docs: AGENTS.md, plugins, hooks, skills, and MCP servers out of the box; config at ~/.grok/config.toml; headless mode via the -p flag for scripts and bots. That’s the public-facing story. The wire-level story is different.

What it sends: the short version

Independent capture on grok 0.2.93 documented three behaviors that matter for anyone about to point this at a private repo.

The uncomfortable part: turns out the git bundle isn’t limited to what the agent reads. It’s the whole repository. Proven directly – 5.1 GB uploaded across 73 chunks before the researcher stopped the stream mid-transfer. With the prompt “reply OK, do not read any files”, Grok still uploaded the entire repo as a git bundle (POST /v1/storage → 200). Git clone-ing the captured bundle recovers a canary file the agent was told not to open – src/_probe/never_read_canary.txt – with its unique marker verbatim, plus the full git history.

Prompting the agent not to read something is not a boundary. It’s a suggestion the agent respects locally, while a separate uploader packages the whole tree anyway.

The setting that doesn’t do what you think

Most people’s first instinct: open settings, turn off “Improve the model,” call it a day.

That’s the red herring. Per the teardown: the mechanism is active by default, and disabling “Improve the model” does not turn it off – docs say this toggle governs training use, but the wire shows /v1/settings still returning trace_upload_enabled: true regardless. None of this proves xAI trains on the data. What is proven is transmission, acceptance, and storage.

The key distinction: “Improve the model” and “send traces” are two different toggles. Only one is exposed in the UI.

Practical setup: a containment recipe

You can still use Grok Build – it’s genuinely capable – but treat the working directory as a broadcast zone. Three steps.

1. Isolate the working tree

Clone into a scratch directory that contains only what you’re willing to upload. Not your monorepo. Not your dotfiles. A subset.

mkdir ~/grok-scratch && cd ~/grok-scratch
git clone --depth 1 --single-branch [email protected]:you/repo.git
cd repo
# strip anything sensitive from history before running grok
git filter-repo --path .env --invert-paths || true
rm -f .env .env.* *.pem *.key

Depth 1 matters. The uploader ships git history – a shallow clone limits the history you’re actually sending.

2. Kill the disk-fill footgun

Separate from privacy, there’s a reliability trap. The upload_queue at ~/.grok/upload_queue stages roughly 3 GB snapshots per turn. Under load, multiple sessions can push it to tens of GB and exhaust the disk entirely – this is a real bug, independent of whether the uploads succeed. On a laptop with a 256 GB SSD, a long session can eat your free space before you notice.

Symlink the queue to a volume you can afford to lose:

mkdir -p /tmp/grok-queue
rm -rf ~/.grok/upload_queue
ln -s /tmp/grok-queue ~/.grok/upload_queue

3. Egress firewall (the nuclear option)

If you’re on macOS, use Little Snitch to allow api.x.ai and deny storage.googleapis.com. On Linux, an iptables rule against the storage endpoint gets you the same thing. The model turn still works. The trace uploader gets a connection refused and moves on.

Is this fully supported by xAI? No. Does it work? Yes – the model turn goes to api.x.ai/v1/responses, the trace goes to a different endpoint, and blocking the second doesn’t break the first.

Advanced usage: headless, subagents, and one changelog line worth reading

Headless mode (-p) is where Grok Build earns its keep – long-running scripted runs, CI pipelines, bots you don’t want to babysit. MCP server support means you can wire in external tools without writing custom plugins.

Subagents run in parallel with their own context windows. Which is great, until you consider that each one is also a network client with the same upload behavior. Fan out four subagents across four worktrees and you’re multiplying transmission, not just compute.

One line from the official changelog is worth internalizing: --no-ask-user now also disables ask_user_question for subagents. The phrasing implies that until this fix, subagents could still prompt for input even when you passed --no-ask-user to the parent. If you’re running headless in CI on an older version, a subagent could quietly stall waiting on a question no human will ever see. Update, or pass the flag and verify the version.

Honest limitations

A few things to be direct about.

• Version-pinned findings. The teardown is against grok 0.2.93 (July 2026). xAI can change behavior at any time – run grok --version and re-check before trusting anything here.
• Not proof of training. Transmission and storage are proven. Whether xAI trains on the contents is a separate policy question the capture didn’t establish.
• Documentation gap is scope-limited. The “not documented” claim is based on the CLI’s install script and quickstart only – not an exhaustive search of all xAI help-center articles or policies. A policy page covering this may exist.
• Every cloud coding agent sends context. That’s the job. The specific issues here: unredacted secrets, persistent named-bucket storage, uploads decoupled from what the agent actually reads.

Compare tools on this axis if you want – Claude Code and Codex CLI face the same category of question. The point isn’t that Grok is uniquely bad. It’s that you should know before running it against a repo with real secrets, and right now the shortest path to knowing is the community teardown, not the docs.

FAQ

Is it safe to use Grok Build CLI in a work repo?

Depends on your company’s policy. If they already allow sending code to xAI’s API, this is directionally the same thing – plus a persistent copy in GCS. If not, don’t.

Can I use Grok Build without uploading anything beyond the model turn?

Not through settings alone, as of grok 0.2.93. The “Improve the model” toggle (covered above) governs training use, not the trace upload channel. The practical workaround is firewalling storage.googleapis.com at the OS level while allowing api.x.ai. You’ll lose whatever server-side features the trace enables, but the interactive agent keeps working. Re-verify after every CLI update – a future release could route uploads differently.

Does this only affect Grok Build, or also the raw xAI API?

The /v1/storage uploader is a CLI-side behavior. If you call grok-build-0.1 directly with curl or the SDK via the xAI API, you send exactly what your code sends – no repo bundle, no session_state archive. Wrappers add behavior; the API doesn’t add it back.

What to do in the next ten minutes

Run grok --version. If you’re on 0.2.93 or earlier, either update and re-test, or apply the three-step containment above before your next session. Then open ~/.grok/upload_queue and check its size – if it’s already over a gigabyte, symlink it out before it fills your disk.