The gist author ran the CLI behind a MITM proxy and found that secret patterns like AWS keys, sk- tokens, ghp_ tokens, and .pem contents pass through intact in outbound request bodies when present in the sampled environment or files. They emphasize that xAI performs no local redaction pass before transmission, meaning sensitive credentials in shell history or env vars get shipped upstream as plain JSON over HTTPS.
The gist explicitly calls out that xAI's terms disabling training on paid-tier API data provide weaker guarantees than users assume. Data still flows to xAI's servers where it's subject to logging, incident response access, subpoena, and breach exposure — regardless of whether it's used for model training.
The editorial frames Grok Build CLI as one instance of a category-wide issue: agentic CLIs like Claude Code, Codex CLI, and Gemini CLI all need filesystem and shell context to be useful, which structurally requires shipping that context to a remote model. The interesting question is not whether Grok sends a lot but how the category should handle the inherent tension between agent utility and local data sovereignty.
The HN submission drove 336 points and 146 comments specifically because the payload list exceeded expectations. Beyond obvious prompt/model/token data, the CLI transmits process environment snapshots, rolling shell history windows, working directory, git branch, git remote URL, and repo root directory listings — a much wider context surface than the 'just my prompt' mental model users held.
A gist published by GitHub user `cereblab` walked through what xAI's Grok Build CLI — the terminal coding agent xAI shipped to compete with Claude Code, Codex CLI, and Gemini CLI — actually transmits during a session. The author ran the CLI behind a local MITM proxy, decrypted its TLS traffic, and dumped the request bodies. The gist hit the Hacker News front page with 336 points, largely because the payload list is longer than most developers assumed.
The CLI sends the obvious things: your prompt text, the model name, and a bearer token to `api.x.ai`. It also sends the contents of files it reads during a tool call, the output of shell commands it executes, and — this is the part that lit up the thread — a serialized snapshot of the process environment and a rolling window of shell history when the agent decides that context is "relevant" to the task. There is a `system` block that includes the current working directory, git branch, git remote URL, and a directory listing of the repo root. None of this is encrypted at the application layer; it's just JSON over HTTPS with a token in the `Authorization` header.
What the CLI does not appear to do is any local redaction pass before shipping that context upstream. The gist's author grepped the outbound bodies for common secret shapes — `AWS_`, `sk-`, `ghp_`, `.pem` contents pasted into a prompt — and found them intact in the request body when they were present in the sampled env or files. xAI's terms say training on API data is off by default for paid tiers, but the gist is careful to point out that "we don't train on it" and "we don't receive it" are very different claims.
Every agentic CLI in this category has the same structural problem: to be useful, the agent needs context; to get context, it reads your filesystem and runs your shell; to reason over that context, it ships it to a remote model. The interesting question isn't whether Grok's CLI sends a lot of data — they all do — it's how much of that data is scoped, redacted, or gated behind an explicit user action. Claude Code, for example, prompts before reading files outside the current working directory and has a documented allowlist system. Codex CLI runs in a sandbox by default and requires opt-in for network access. Gemini CLI has a `--yolo` flag precisely because the safe default is friction.
The HN thread converged on three concrete complaints. First, the env-var dump is opportunistic — the CLI sends whatever is in `process.env` at the moment it decides environment context is useful, which on a developer laptop means database URLs, cloud credentials, and third-party API keys. Second, the shell history slice includes commands from other projects in the same terminal session; a `psql` connection string you ran an hour ago is fair game. Third, there's no local audit log — the CLI doesn't show you what it just sent, so the only way to know is to proxy it yourself, which is what the gist author did.
xAI's response, so far, has been silence, which is its own signal. The competitive framing here is unflattering: Anthropic publishes a data usage doc for Claude Code that enumerates what leaves the machine; OpenAI's Codex CLI has an open-source client so you can read the transport code directly; Google publishes Gemini CLI's telemetry schema. xAI ships a closed binary and a terms-of-service page. For a company whose pitch is "maximum truth-seeking," a black-box telemetry story is a bad look — and one the community will keep poking at until there's a proper disclosure.
There's also a second-order point worth naming. Coding agents are quietly becoming one of the largest new sources of accidental secret exfiltration inside engineering orgs. Pre-commit hooks, GitHub secret scanning, and CI redaction all assume the threat model is *committed code*. An agent that reads your `.env` file and POSTs it to a third party bypasses every one of those controls, and it does so on the happy path, not the misuse path. Your SOC 2 auditor is going to have opinions about this in about six months.
If you or your team are evaluating agentic CLIs — Grok Build, Claude Code, Codex CLI, Gemini CLI, Cursor's agent, or the growing pile of wrappers on top of them — the useful questions are no longer about model quality. They're about the wire format. Concretely, before you approve a tool for company use, ask the vendor:
1. What exactly is in the request body on a typical tool call? Not "prompts and context" — the actual JSON schema. 2. Is there a local redaction step? If so, what patterns does it match, and is it configurable? 3. Does the client send environment variables? Shell history? Git remote URLs? If yes, is any of it opt-in? 4. Is there a local audit log the user can inspect to see exactly what left the machine in the last session? 5. What's the data retention policy on the server side, and does it apply per-session or per-account?
If the vendor can't answer these in a paragraph, you have your answer. For individual developers who want to keep using Grok's CLI in the meantime, the workable mitigations are unglamorous but effective: run the CLI in a dedicated terminal with a scrubbed environment (`env -i` plus only what the project needs), keep it out of directories containing `.env` files you haven't audited, and put it behind a proxy so you can at least see what it's doing. A `direnv`-scoped shell with a minimal env is probably the lightest-touch way to bound the blast radius.
For teams, the right move is probably to require agentic CLIs to run inside a devcontainer or a per-project sandbox with an explicit env allowlist, the same way you'd treat any binary that has network access and reads arbitrary files. This is what large orgs already do for CI runners; it's now the same problem class on the laptop.
The Grok CLI story will pass — xAI will either publish a real data-flow doc or lose this segment to competitors that already have. The bigger shift is that "what does this coding agent send on the wire" is going to become a standard procurement question, and vendors that can't answer it crisply are going to lose enterprise deals in 2026. Expect a wave of `agent-audit`-style open-source proxies over the next few months, and expect at least one high-profile secret leak traced back to an agentic CLI before the year is out. The tools are too useful to stop using; the defaults just have to get a lot more conservative.
I always separate the coding tools from LLM providers, and use bubblewrap to sandbox the coding tools so they:1. Can only read the working project directory, with .git read-only and sensitive directories hidden (mounted as empty directories).2. Have an isolated network namespace; they can only acces
This is one of the reasons why native proprietary coding agent runners like claude-code, codex, grok-build etc are so dangerous for privacy… you just don’t know what “secret sauce” they’ll add in the next update…It’s much safer to use something like opencode and use models via their API… however, th
"It uploads the whole repository — every tracked file's content plus git history — independent of what the agent reads"Holy cow!!!! I mean I kinda expected Elon would do something like this to try to catch-up.. but this is extremely concerning.This is precisely the reason, even though
I wish a human would’ve written the overview.Nonetheless, this is disturbing.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
Mitigation for use: ``` export GROK_TELEMETRY_TRACE_UPLOAD=0 export GROK_TELEMETRY_ENABLED=0 # or config file with [telemetry] trace_upload = false, [harness] disable_codebase_upload = true ``` The practical takeaway for users: your entire codebase leaves (uploaded) your machine unencrypted on each