Grok CLI uploaded the whole home directory to GCS

TL;DR Highlight

Running Grok in a home directory allegedly uploaded SSH keys and personal files to xAI servers.

Who Should Read

Developers who run coding agent CLIs on their local machine without restricting file or network access.

Core Mechanics

User claims whole home directory was uploaded
- One user posted on X that Grok uploaded their entire user directory to xAI's servers.
- They say it included SSH keys, a password manager database, documents, photos and videos.
Logs allegedly show upload traces
- Another user claimed Grok Build uploads 12GB of repo data and full git commit history to GCP.
- They suggested grepping repo_state.upload in ~/.grok/logs/unified.json to check.
Kill switch reportedly said off, uploads happened anyway
- A post says settings returned a global kill switch disable_codebase_upload: true.
- The same post says Codex and Anthropic found indirect evidence that 8 private repos were fully uploaded.
User behavior was also criticized
- Another user replied that running Grok in the home directory was itself the bigger problem.
Source is X posts with no official xAI response
- The source contains no explanation or fix from xAI.

Community Reactions

Upload is a tool decision, not the LLM's, some argue
- Commenters said the agent did not choose to read files; the tool seems to deterministically upload the repo at session start.
- They said server-side embedding might be the reason, but not worth it since other agents use local grep/ripgrep.
Sandbox setups people already use
- One commenter runs agents in podman containers and brings back only git patches.
- Another uses a dedicated dev user whose home holds only repos.
- Another runs Opencode in WSL2 with Windows mounts disabled.
Instruction files can't be trusted as a barrier
- Commenters argued .md instruction files give no guarantee that agents obey them.
- Some said to assume any agent will read anything.
It's not only the user's fault, some say
- Commenters said the agent shouldn't be expected to do this and called it poor engineering at xAI.
- Some thought server-side features should be opt-in rather than opt-out.

How to Apply

Check your logs for upload traces
- If you've used Grok Build, grep repo_state.upload in ~/.grok/logs/unified.json today.
- If found, check whether secrets were in that path and rotate them.
Run agents only inside a repo
- Launch the CLI inside the repo you work on, never in your home directory.
- Create a dedicated OS user whose home holds only repos and run agents as that user.
Run agents in containers or VMs
- Mount only the needed repo into a podman or Docker container.
- Pass only necessary env vars and network access, and bring results back as git patches.
Test new agent CLIs in a sandbox first
- Try unfamiliar tools in a cloud sandbox or empty VM first.
- Watch outbound traffic to see what leaves before installing locally.

Try It

copy & run

# Run in terminal: check agent CLI upload traces and a simple container isolation example
# 1) Look for upload records in Grok Build logs (command from the source)
cat ~/.grok/logs/unified.json | grep repo_state.upload

# 2) Open a shell in a container with only the current repo mounted (no network, no home directory access)
podman run --rm -it --network=none -v "$PWD":/work -w /work docker.io/library/debian:stable bash

# Next: remove --network=none and add a proxy allowing only needed domains to inspect outbound traffic

Terminology

SandboxA fenced-off play area limiting what an agent can touch. Containers and VMs are typical examples.

Kill switchAn emergency switch that remotely turns a feature off. Here it refers to a setting disabling codebase upload.

EmbeddingTurning text into number vectors where similar meanings sit close together. Used to build search indexes.

ExfiltrationSecretly moving internal data out. Like sneaking items out in a shipping box.