Grok CLI uploadde je hele home directory naar xAI — wat er misging en hoe je stopt

Stand van zaken 16 juli 2026:de whole-repo-upload van Grok Build is sinds 12 juli server-side uitgezet, Musk beloofde alle eerder verzamelde coding-data te wissen, en de codebase van Grok Build staat sinds 15 juli op GitHub onder Apache 2.0 (Bron: Simon Willison). Dit stuk beschrijft wat er tussen 10 en 15 juli precies gebeurde, waarom het meer was dan “AI stuurt code naar de server”, en wat je zelf nu kunt doen.

Er zit een groot verschil tussen “AI-tool stuurt code naar de server om te reageren” en “AI-tool zuigt je hele werkmap op — inclusief bestanden die je nooit hebt geopend — en zet er een kopie van bij Google in de cloud”. Precies dat tweede deed xAI’s officiële Grok Build CLI, standaard, en zonder dat de “Improve the model”-toggle er iets aan veranderde. Eén gebruiker draaide ‘m in zijn home directory en zag zijn SSH-keys, password manager en foto’s naar xAI vertrekken. Hier lees je wat er is gebeurd, wat xAI erover zegt, en hoe je zelf checkt of je risico loopt.

Om welke tool het precies gaat

De tool die de afgelopen dagen op Hacker News trending stond is Grok Build, de coding-CLI van xAI (inmiddels SpaceXAI). Je installeert ‘m met één regel — curl -fsSL https://x.ai/cli/install.sh | bash — en logt in met je gewone consumer-account. In je terminal heet het commando gewoon grok, en het binary is een Rust-executable (Bron: xai-org/grok-build).

Beginner-tip:verwar dit niet metgrok-clivansuperagent-aiop GitHub. Dat is een community-project van iemand anders, staat er los van en heeft niets met dit incident te maken. Het gaat hier specifiek om de officiële xAI-tool, waarvan de versie in de wire-analysegrok 0.2.93was.

Grok Build is de tegenhanger van Claude Code, GitHub Copilot en Cursor. Onze review van Claude Code op debesteaitools.nl beschrijft hoe zo’n coding-agent werkt: je opent ‘m in een projectmap, hij leest bestanden, schrijft code, draait tests. De impliciete afspraak: hij ziet alleen wat je nodig hebt om je taak op te lossen. Dat bleek bij Grok niet te kloppen.

Wat er werkelijk werd verstuurd

Op 10 juli 2026 publiceerde een onderzoeker onder de naam cereblab een wire-level analyse van Grok Build 0.2.93: mitmproxy tussen de CLI en xAI’s servers, met alle requests en response-codes op tape (Bron: cereblab-gist). Twee dagen later stond de analyse boven aan Hacker News, met 172 stemmen en meer dan 60 comments.

Wat de analyse liet zien, kwam op twee gescheiden dataroutes neer:

Om te bewijzen dat kanaal B echt onafhankelijk van de opdracht is, deed de onderzoeker een controle-run op een testrepo van 12 GB met puur willekeurige bestanden, met de expliciete prompt “Reply exactly OK, do not read any files”. Resultaat: kanaal A verstuurde 192 KB (het model deed dus niks met de bestanden), maar kanaal B pompte in 73 opeenvolgende chunks van ongeveer 75 MB 5,10 GiB aan bestanden richting Google Cloud Storage-bucket grok-code-session-traces — allemaal met HTTP 200 als antwoord. De verhouding tussen “wat het model daadwerkelijk las” en “wat xAI opsloeg” was ongeveer 27.800 keer groter dan nodig.

Op een tweede, echte codebase legde hij het smoking gun neer: hij deponeerde een bestand src/_probe/never_read_canary.txt met een unieke marker, vroeg Grok expliciet niets te openen, en captureerde de upload. git clone op de opgevangen git bundle produceerde de repo mét het marker-bestand, letterlijk, plus de volledige commit-geschiedenis. Wat er de deur uitging was dus geen hash of manifest — het waren de bestanden zelf.

Gevorderden:de upload gebruikt een intern Rust-cratexai-data-collectormet een aparte upload-coordinator die presigned PUT-verzoeken naarstorage.googleapis.comdoet. Eennettop-meting op de CLI-PID mist die uploads, want ze gaan langs een ander proces én rechtstreeks naar Google-IP’s. Dat is waarom eerdere pogingen om het gedrag met terminal-tools te weerleggen, verkeerd concludeerden dat “er niets vertrok”.

Waarom het incident meer was dan een codebase-lek

Wat de meeste rumoer maakte op X en Hacker News was niet de codebase-upload op zichzelf, maar wat er gebeurde toen één gebruiker — @a_green_being — het commando in zijn eigen home directory (~/) draaide. In zijn X-post beschreef hij dat Grok “mijn SSH-keys, mijn password manager-database, mijn documenten, foto’s, video’s, alles” had geüpload (Bron: HN-thread — samenvatting via Simon Willison). De reden is banaal: de CLI behandelt de working directory als “repo”, ongeacht wat erin zit. Wie zijn home directory ooit onder git heeft gezet (voor dotfiles-beheer bijvoorbeeld), of gewoon een grok-sessie in ~/ startte, kreeg het volle pakket mee als git bundle.

Voeg daaraan het .env-verhaal toe uit dezelfde analyse: elke .env die de agent bij zijn taak opent — en dat doet hij nogal snel — werd verbatim in het model-verzoek meegestuurd. API-keys en database-wachtwoorden verschenen ongeredigeerd in het request-body. Op een normale developer-machine ligt dat direct in Kanaal A én in Kanaal B, en dus in twee kopieën in de bucket.

Beginner-tip:een.env-bestand is de standaardmanier waarop projecten gevoelige waardes (API-keys, wachtwoorden) buiten hun code houden. Ze horen expliciet níet gedeeld te worden — daarom staan ze in.gitignoreen horen ze nooit in een repo-snapshot. Grok Build behandelde ze desondanks als leesbaar bestand.

Wat xAI daarna deed

De reactie van xAI kwam getrapt. Op 13 juli deed een medewerker mee in de discussie op X en wees op de bestaande Zero Data Retention-modus (ZDR) plus de /privacy-commando binnen de CLI om je voorkeur te veranderen en eerder gesynchroniseerde data retroactief te wissen. Musk zelf zei diezelfde dag: “As a precautionary measure, all user data that was uploaded to SpaceXAI before now will be completely and utterly deleted” (Bron: The Register).

Wat objectief te controleren viel: op 13 juli deed dezelfde onderzoeker zes herhaalruns en zag nul uploads naar /v1/storage. De server retourneerde inmiddels trace_upload_enabled: false en disable_codebase_upload: true. De code werd niet aangepast — er ging een server-side vlag om. Op 15 juli publiceerde xAI de complete Grok Build-broncode onder Apache 2.0 op xai-org/grok-build (844.530 regels Rust, aldus Simon Willison’s telling), inclusief de crates die de upload-logica bevatten (Bron: Simon Willison). Reste van de upload-code — de upload_session_state()-functie in xai-grok-shell/src/upload/trace.rs — retourneert nu simpelweg de foutmelding session_state_upload_unavailable.

Eén ding wat xAI niet uitlegde, is waarom de whole-repo-upload er stond. Officiële communicatie over de motivatie (“training”, “session recovery”, “telemetrie voor debugging”?) is er tot nu toe niet, en dat is een openstaande vraag. Wat xAI wel zegt in hun eigen aankondigingsthread: retentie stond bij launch aan voor niet-ZDR-gebruikers, en die default staat sinds 12 juli uit. Voor jou als gebruiker verandert er dus feitelijk iets — maar de reconstructie waarom dit ontwerp er überhaupt kwam, moet nog komen.

Hoe je nu checkt of jij Grok CLI hebt

Vier commando’s die in dertig seconden duidelijkheid geven:

# 1. Staat het binary in je PATH?
which grok

# 2. Bestaat de configuratiemap?
ls -la ~/.grok/ 2>/dev/null

# 3. Staat er een upload_queue met oude staged snapshots?
ls -la ~/.grok/upload_queue/ 2>/dev/null

# 4. Zit het misschien als npm/pnpm-pakket geïnstalleerd?
npm ls -g 2>/dev/null | grep -i grok
pnpm ls -g 2>/dev/null | grep -i grok

Als één van de eerste drie iets teruggeeft, heb je de officiële xAI-CLI ooit geïnstalleerd. Wat je dan doet:

1. Draai /privacy in de CLI om je huidige instellingen te zien en, als je dat wil, retroactieve verwijdering aan te vragen — dat is de door xAI aangewezen route.
2. Verwijder de binary en config: rm -rf ~/.grok && rm ~/.local/bin/grok 2>/dev/null || rm /usr/local/bin/grok 2>/dev/null (pas het pad aan aan waar which grok naar wees).
3. Roteer alle API-keys en wachtwoorden die in .env-bestanden stonden in mappen waar je Grok ooit hebt gedraaid, zeker vóór 12 juli. Ga uit van blootstelling, ook als xAI’s verwijdering slaagt.
4. Overweeg voor toekomstige coding-agents een sandbox — een container, een aparte gebruiker, of iets als devcontainers. Onze eerdere analyse van wat een AI-agent eigenlijk mag doen op jouw machine laat zien waarom die grens zo makkelijk verschuift zonder dat je het merkt.

Wat dit voor jou en je bedrijf betekent

Voor consumenten: als je Grok Build niet hebt geïnstalleerd, gaat dit incident goeddeels aan je voorbij. Als je ‘m wel gebruikte, is de kans op reëel schade beperkt tot wat er in je codemappen stond — mits Musk’s verwijderingsbelofte wordt nagekomen. Roteer voor de zekerheid je gevoelige credentials.

Voor developers: dit is de tweede grote “closed-source coding-agent lekt meer dan verwacht”-episode in korte tijd (na eerdere zorgen over metadata in Claude Code). De praktische les is niet “gebruik geen coding-agents”, maar: behandel elke coding-agent als een tool met netwerktoegang die alles kan lezen wat jij kan lezen. Sandboxen, niet in je home dir draaien, geen .env in dezelfde folder als de agent, en accepteer dat de vendor-belofte niet je enige beschermlaag mag zijn.

Voor MKB: dit is AVG-relevant zodra er klantdata op de betreffende machine staat. Ook als die klantdata níet in de repo staat maar in de map ernaast, is de vraag of het door de agent kon worden gelezen. Voor ondernemers die willen weten wat je in je bedrijf toelaat en welke abonnementsvorm past bij welk risicoprofiel: onze gids over AI-abonnementen kiezen voor het MKB op aiplatformmkb.nl helpt je die keuze structureel maken, in plaats van per incident.

Eén ding dat wel positief opvalt: xAI’s stap om de hele codebase open source te maken, is meer dan een symbolisch gebaar. Wie de bron nu kan lezen, kan zelf zien welke tools de agent tot zijn beschikking heeft, welke prompts eraan hangen, en wat de upload-code doet — of niet meer doet. Dat is precies wat de discussie op Hacker News al twee jaar bepleit als scenario voor “closed-source AI-tooling”: als je de bron kunt lezen, kun je je risico beoordelen. Voor Grok Build kan het nu.

Voorlopig weten we dit — houd je oog open

xAI heeft de blooding gestelpt: upload uit, data-belofte gedaan, code open. Wat we níet weten is waarom de whole-repo-upload er in eerste instantie kwam, of Musks belofte een audit-trail achter zich krijgt die verantwoordelijke bedrijven kunnen gebruiken, en of er verwerkersovereenkomsten komen die specifiek naar dit incident verwijzen. Voor de gemiddelde lezer verandert er de komende dagen niets. Voor developers en ondernemers die klantdata op hun machine hebben, is de rustige actie: check of je ‘m hebt, roteer wat gevoelig is, en gebruik dit als aanleiding om te bedenken hoe je toekomstige coding-agents wilt inperken vóór ze in je home dir landen.