Your AI coding tool might be uploading your entire repo

Quick answer

Assume any agentic AI coding tool (the kind that reads your files and edits code) may transmit your repository to its vendor. Some do it on start, before any prompt. To defend yourself: (1) never run an interactive agentic CLI inside a repo that holds secrets or code you can't share; (2) keep secrets out of the tracked tree (.gitignore them) and out of files the agent reads; (3) prefer headless one-shot modes or a REST API over the interactive session; (4) if you must, run it in a throwaway directory with nothing sensitive. Audit before you trust — the method is below.

What just happened — the Grok Build case

On 12 July 2026, independent testers reported that Grok Build (xAI's agentic coding CLI, v0.2.93) uploads the user's entire git repository — as a bundle including complete commit history and files the agent never opened — to xAI's Google Cloud Storage. Tests measured multiple gigabytes of repo data leaving the machine.

Asked directly, xAI's official @grok account confirmed it in its own words: "Independent wire-level analysis (mitmproxy captures + canary file tests) confirms Grok Build CLI uploads your full Git repo as a bundle — including complete history and files the agent never reads — to xAI's Google Cloud Storage by default. Read files like .env secrets are also sent verbatim. This is not stopped by the 'Improve the model' toggle." It added that the upload is "the current design for reliable agentic performance" and that granular controls were "in active development."

The important part for your threat model: the upload fires when you start the tool, not when you ask it to do something. A user who opened it and typed nothing still had their repo shipped.

Why agentic tools do this

It isn't (necessarily) malice — it's the design. An agent that reasons across your codebase wants complete, consistent context: every file, the git history, the relationships between modules, so its subagents and worktrees don't work from a broken partial view. The fastest way to give a cloud model that is to ship the whole repo up front. Convenience for the agent, exposure for you.

That trade-off is invisible unless you look. The tool "just works," and the several gigabytes leaving your NIC don't show up in the chat window. This is exactly the kind of default that a privacy-minded operator has to assume is present until proven otherwise.

What actually leaks

• All tracked source — every file committed to git, whether or not the agent read it.
• The full commit history — not just the current tree. Anything ever committed and later "removed" still lives in history and goes up with the bundle. Deleting a secret in a later commit does not delete it from the repo.
• Files the agent reads — sent verbatim. If it opens a .env to understand config, that file's contents leave with it, even if the file is gitignored.
• Not gated by the obvious toggle — in the Grok case, the "Improve the model" opt-out did not stop the upload. Opt-outs you'd expect to help may not touch this path.

The risk math — what saves you, what doesn't

Two mechanisms decide your exposure:

• The git bundle carries tracked files + history. So a secret that was never committed — kept in a gitignored file like .env / .dev.vars — is not in the bundle. This is why .gitignore discipline is your first and cheapest line of defense.
• Read-file capture carries whatever the agent opens, gitignored or not. So .gitignore alone is not sufficient if you then let the agent read the secret file. Keep secrets out of the agent's reach entirely.

Worked example: we audited our own exposure after running an agentic CLI in a real repo. Our live secrets sat in a gitignored, never-committed .dev.vars — so they were absent from the uploaded bundle. The only tracked env file held a public site key (safe by design). Net result: our source and history went up; our secrets did not. .gitignore is what drew that line. It could just as easily have gone the other way for a repo that commits its .env.

It's not just your repo — the session grabs your whole environment

Here's the part that makes .gitignore a false comfort. When a developer had a second AI agent (an OpenAI Codex CLI) inspect what the interactive tool had actually done on their Mac, the audit found the leaked context reached well past the tracked repo. Alongside the git bundle, the session had captured:

• the directory tree of an adjacent project — source layout, package files, asset and dependency names it was never asked about;
• the text of a hand-off / notes document sitting in that project;
• terminal output containing the macOS username, local account names, and an email address — real-world identity, not code;
• paths to another AI tool's local project and session files — effectively a map of the rest of the developer's stack.

None of that falls under .gitignore. Gitignore keeps files out of the git bundle; it does nothing about terminal output, files in neighbouring folders, or the fingerprints of your other tools that an interactive session reads and folds into its context. The moment you open an agentic session in a working environment, the environment is the attack surface — your username, your email, your adjacent repos, your notes. For a pseudonymous operator that username-plus-email pairing is the whole game: it can undo months of compartmentalization in a single upload.

The lesson isn't "gitignore harder." It's that the only reliable boundary is the directory you launch the tool in — and everything that directory and your shell can reach. Treat an interactive agentic CLI as if it photographs the entire room, not just the file on the desk.

Audit your own tool — the method that outlives the news

Don't trust a vendor's blog post or a stranger's screenshot, including this one. Verify on your own machine. Three techniques, cheapest first:

1. Canary files. Drop a uniquely-named file with a unique random string into a test repo (e.g. CANARY-9f2c4a.txt). Run the tool. Then search the vendor's storage, your account's data-export, or simply watch whether that string ever appears in a request body. If a file you never referenced leaves the machine, you have your answer.
2. Wire-level capture. Point the tool through a local intercepting proxy (mitmproxy) and read what it actually sends. Look for multipart uploads, bundle/tar/git payloads, and request sizes far larger than your prompt. This is how the Grok behavior was proven; it's reproducible in an afternoon.
3. Egress size. Even without decrypting TLS, watch total bytes sent right after launch (a per-app network monitor, or nettop / iftop). A one-line question that triggers a multi-gigabyte upload tells you everything.

Do this once per tool, and re-do it after major updates — behavior changes silently between versions.

Sandbox it — practical policy

• Never launch an interactive agentic TUI inside a real repo. That session-start bundle is the worst offender. If you need the interactive experience, do it in a throwaway directory containing only the files you're willing to share.
• Prefer headless / one-shot modes. Many tools have a non-interactive "answer this one prompt" mode that does not bundle the repo. In our own testing of one such tool, headless -p invocation uploaded nothing, while opening the interactive TUI in a repo did. Verify yours the same way — the distinction matters.
• Use a REST API over the CLI where available — API calls typically send only the context you pass, not the whole tree.
• Gitignore secrets religiously, and never point the agent at a secret file. Keep .env / key material out of both the tracked tree and the agent's read scope.
• Enterprise "zero data retention" tiers exist for some tools — but they're a contractual promise, not a technical guarantee you can verify. Treat accordingly.
• Self-host the model for genuinely sensitive work. A local model (see our local-models guide) sends nothing to anyone. It's the only option that removes the vendor from your threat model entirely.

Bottom line

Agentic AI coding tools are a genuinely new exfiltration surface: a program you invited in that reads everything and, by default, may ship it upward — silently, at session start, past the toggles you'd expect to protect you. The Grok Build disclosure is notable only because the vendor confirmed it out loud; assume the same posture from every agentic tool until you've verified otherwise. Keep secrets out of the tree and out of the agent's hands, run interactive sessions in disposable dirs, prefer headless modes, and — for anything that truly matters — run the model locally. Convenience defaults are set for the vendor. Your threat model is your job.