The original reporter provided packet captures and GCS request logs showing Grok CLI multipart-uploading .ssh/, .aws/credentials, dotfiles with API tokens, and Firefox's logins.json and key4.db to xAI's bucket. The framing is that this is not a theoretical risk — actual live credentials and password databases left the machine on first invocation.
Independently observed the same behavior on a fresh laptop by watching egress traffic, confirming this isn't an isolated misconfiguration but a reproducible code path. Frames the incident as a systemic exfiltration issue affecting any user who runs Grok CLI outside a git repo root.
Argues the technical upload isn't the whole story — xAI shipped a prompt reading 'Grok can read files in your project to answer questions' while the code walks up to $HOME when no git root is found. This is a UX/consent design failure as much as a security one, because users reasonably assumed 'project' meant the current directory.
Frames Grok CLI as a symptom rather than an outlier: shipping a working code path that tarballs $HOME is not an accidental bug but something that was written, reviewed, and shipped without anyone flagging that SSH keys live there. Implicitly indicts the whole Claude Code / Codex CLI / Aider category for treating filesystem context as an unbounded default.
Notes xAI has not issued a statement, disabled the endpoint, or pushed a CLI update while user credentials continue to be uploaded. The 'looking into it' reply from a support engineer is characterized as the industry-standard holding pattern before a longer silence, suggesting incident response is inadequate to the severity.
On July 12, developer @a_green_being posted a thread showing packet captures and GCS request logs indicating that xAI's Grok CLI — the terminal coding agent xAI shipped earlier this year to chase Claude Code and Codex CLI — had uploaded the entire contents of `$HOME` to a Google Cloud Storage bucket under xAI's project. The screenshots show multipart uploads of `.ssh/`, `.aws/credentials`, `.config/`, dotfiles containing API tokens, and, most alarmingly, the developer's Firefox profile directory including `logins.json` and `key4.db`.
A second Hacker News thread (score 112 at time of writing, climbing) surfaced the same behavior from an independent user who noticed egress traffic while running Grok CLI on a fresh laptop. The pattern is consistent: on first invocation inside any directory that isn't a git repo root, the CLI walks up to `$HOME`, tarballs everything under a size cap, and POSTs it to `storage.googleapis.com` under what appears to be xAI's `grok-cli-context-v2` bucket. There is a consent prompt — but it says "Grok can read files in your project to answer questions. Continue?" with no indication that "project" is being interpreted as the entire user account.
xAI has not, as of this writing, issued a statement, disabled the endpoint, or pushed a CLI update. The company's status page is green. A support engineer replied on X saying the team is "looking into it," which is the industry-standard holding pattern before a longer silence.
The interesting question isn't whether this was malicious — it almost certainly wasn't. It's how a shipping product from a well-funded lab reached users with a working code path that treats `$HOME` as the default context window. That's not a bug you write on accident. Someone typed it, someone reviewed it, someone shipped it, and nobody in that chain flagged that SSH keys live in `$HOME`.
The more useful frame is what this says about the entire category. Claude Code, Codex CLI, Aider, Cursor's agent mode, Gemini CLI — all of them run as your user, with your permissions, and all of them have some notion of "gather context." The difference between a well-behaved agent and Grok's failure mode here is one config flag and a couple of `if` statements. Every AI CLI you run today is one bad default away from being an exfiltration tool, and the industry has no meaningful sandboxing story.
Compare this to the browser security model, which took twenty years and multiple catastrophes to reach today's per-origin sandboxing, permission prompts with real granularity, and process isolation. Terminal-based AI tools are currently at roughly the 1998 Internet Explorer stage: they run with full user privileges, they have network egress to arbitrary endpoints, and the "permission model" is a single yes/no prompt at install time. The community has been talking about this since Simon Willison's prompt-injection posts in 2023, but nothing has materially changed at the tooling layer.
The HN comments are split between two camps. The security-minded contingent — led by a top comment from a former Google SRE — argues that any tool with LLM-driven filesystem access needs to run in a mandatory bubblewrap/firejail/container sandbox with a per-invocation allowlist, and that the CLI vendors are negligent for not shipping this. The pragmatist camp counters that sandboxing breaks the actual value prop ("the whole point is that it can see my code") and that the responsibility lies with users to not run untrusted tools as their normal account. Both are right, which is why nothing gets fixed.
There's also a legal dimension worth flagging. If a developer at a company with any data-handling obligations — HIPAA, SOC 2, PCI, GDPR, ITAR, take your pick — ran Grok CLI on their work laptop and it exfiltrated customer data or credentials, that's a reportable breach. xAI is now, involuntarily, a data processor for every developer who ran their tool. The Terms of Service disclaim this, but ToS don't override statutory breach-notification law. Expect at least one Fortune 500 to send a very unpleasant letter this week.
Stop running AI CLIs as your normal user. This is the single highest-leverage change you can make today, and it takes ten minutes. Create a dedicated `ai-agent` user with no sudo, no access to `~/.ssh`, no access to your password manager, no access to browser profiles. Bind-mount only the specific project directory you want the agent to see. On Linux, `systemd-run --user --property=ProtectHome=tmpfs --property=PrivateNetwork=no` gets you most of the way there for free. On macOS, use a separate user account and `su - ai-agent` before invoking anything. This isn't paranoid — it's the minimum bar for running arbitrary code that phones home.
If you must run an AI CLI as yourself, put egress behind a proxy you control and log every outbound request. `mitmproxy` in transparent mode, or a simple `iptables` rule that only allows the vendor's documented API endpoints, will catch this class of behavior in seconds. The Grok upload was to a GCS bucket, not to `api.x.ai` — a domain allowlist would have blocked it and given you a loud, obvious failure to investigate. If your AI tool refuses to work through a proxy, that itself is signal.
Audit your credential hygiene assuming any AI CLI you've run in the past six months has seen everything in `$HOME`. Rotate anything sensitive: cloud provider access keys, GitHub personal access tokens, `.npmrc` auth tokens, SSH keys, browser-stored passwords. This is annoying but cheap compared to the alternative. Move long-lived secrets out of dotfiles entirely — use `pass`, `1password-cli`, `aws-vault`, `gh auth`, or your platform's keychain, all of which require an explicit unlock and don't sit in plaintext on disk.
The pattern here — well-funded lab ships coding agent, coding agent has embarrassing security failure, lab issues a terse apology, everyone forgets in six weeks — is going to repeat. The economics guarantee it: shipping fast beats shipping safe when the market is being carved up in real time, and the users who care about sandboxing are a rounding error next to the ones who want tab-completion for their entire codebase. The right move as a practitioner is to stop expecting vendors to solve this for you and treat every AI CLI as untrusted code that happens to be useful. Grok won't be the last one caught doing this. It'll be the last one caught doing it *this month*.
Important to clarify that this was not the Grok agent deciding to read the files.I don't think the LLM had anything to do with this decision at all. It looks like the Grok tool starts a session by deterministically kicking off a full upload of the user's current repository (and maybe their
I remember a time when we were told not to run obscure software from questionable websites on our computers. And yet, people are suddenly fully vibing with an uncontrollable character generating machine with who-knows-what-behind-the-scene harness. Crazy.
Xcancel link https://xcancel.com/a_green_being/status/2076598897779020159
The question is why would it not? Don’t people know that these AI agents run in the cloud?
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
So many of the replies are saying that they should've restricted access using .md files and whatnot. Is really any guarantee that they even follow those? It seems like even if you ask pretty please don't touch those files, there's a chance they will. So many people have just willingly