xAI’s Grok Build Coding Tool Exposed Users’ Full Codebases Before Shutdown

xAI has disabled a Grok Build coding feature after researchers found it was uploading users’ entire code repositories to cloud storage, including material developers had explicitly excluded. The company says the data collected before the change will be deleted, but the incident has raised fresh questions about AI coding assistants, privacy controls, and how much source code users are really giving away.

The issue surfaced after independent researchers examined Grok Build’s command-line tool and reported that it was packaging and sending full codebases to Google Cloud. The behavior stood out because it went beyond what users would normally expect from an AI coding assistant, and it appears to have exposed sensitive material that could include secrets, vulnerabilities, and private infrastructure details.

What happened with Grok Build?

Grok Build, an AI-powered coding tool associated with xAI, was found to be transferring users’ repositories in full to cloud storage before the company intervened. According to reporting from The Register and findings published by researchers at Cereblab, the tool was not merely uploading snippets relevant to a query. It was sending entire codebases, including files the system had been told not to inspect and material that had already been removed from version history.

The behavior was alarming because code assistants typically rely on limited context, targeted file access, or user-approved scopes. In this case, the researchers say the tool was handling much broader data than expected. That meant developers could have unintentionally exposed far more than a small section of source code.

By Monday, the researchers said the server-side behavior had changed. Their tests reportedly showed a flag indicating codebase uploads were disabled, and the upload process no longer triggered. In practical terms, the feature that had been sending repositories outward appears to have been turned off after the problem was identified.

Why does this matter for developers?

It matters because source code is often the crown jewel of a software team’s intellectual property, and repository uploads can expose more than just application logic. Code can reveal authentication tokens, deployment details, internal services, third-party integrations, and even security weaknesses that attackers could exploit.

Security researchers warn that the risk is not theoretical. A full codebase can contain hardcoded credentials, API keys, environment variables, comments about unfinished fixes, and references to internal infrastructure. Even if a company intends to use cloud processing only temporarily, the presence of that data in a third-party environment changes the threat model significantly.

Independent security researcher Dr. Lukasz Olejnik, of King’s College London, said the level of data retention involved was excessive and could put proprietary code, vulnerability details, personal information, infrastructure data, and credentials at risk.

That is a particularly important warning at a time when AI coding tools are becoming more common across startups and large enterprises. The selling point of these tools is convenience: they can summarize code, generate tests, refactor files, and help developers move faster. But that productivity gain only works if the data handling behind the scenes matches the trust users place in the system.

How did the data exposure work?

According to the researchers, the Grok Build CLI was bundling and uploading repositories in a way that appeared broader than comparable tools. The uploads reportedly included content the system had been instructed not to open and data that had already been deleted from history, suggesting the tool’s retention and access behavior was not limited to what a user would reasonably expect.

The detail that the uploads went to Google Cloud also matters. While cloud services are common in AI workflows, the question here is not whether cloud storage exists at all, but whether the tool had clearly disclosed what was being retained, for how long, and under what controls. In many organizations, that is the difference between a manageable workflow and a compliance nightmare.

What kinds of information could have been exposed?

The likely exposure could have included proprietary source code, security fixes, environment configuration, deployment information, personal data, and credentials. Even if not every repository contained all of those elements, the fact that entire codebases were being transferred created a much wider blast radius than a narrower file-level process would have.

For teams building internal tools, customer-facing software, or infrastructure services, that risk is especially serious. A single leaked repository can provide attackers with enough context to move deeper into a network or to target related services with phishing, credential stuffing, or supply-chain attacks.

How did xAI respond?

xAI’s response, as described in the source reporting, came in stages. First, the company said that if zero data retention had been turned off, users could use the /privacy command in the CLI to disable retention, and that doing so would also remove previously synchronized data.

Researchers pushed back on that explanation, arguing that /privacy was only a per-session setting and not the specific control that stopped the repository uploads themselves. In other words, the tool’s visible user setting and the actual upload behavior were not the same thing, which creates confusion for anyone trying to understand how their data is handled.

Later, Elon Musk said on X that all previously uploaded data would be deleted and described the deletion as complete. He also asserted that privacy settings are always respected, while simultaneously encouraging users to permit data retention because it could help with debugging. That combination of deletion promise and retention pitch is consistent with Musk’s broader pattern of pushing aggressive product iteration while publicly downplaying concern over temporary data collection.

Musk said the previously uploaded data would be fully deleted and argued that allowing retention can help diagnose technical issues, while also insisting that user privacy settings should be honored.

That statement may reassure some users, but it does not answer every question about how long the data was retained, who had access to it, and whether the material could have been propagated to backups or logs before deletion was ordered.

What changed after the report?

The most immediate change was that the codebase upload behavior appears to have been shut off. The researchers said that server responses later included a setting indicating codebase uploads were disabled, and their testing showed the upload step no longer occurred.

That kind of quick reversal suggests the company recognized the problem as material rather than theoretical. When an AI tool is silently collecting more data than it should, turning off the feature is only the first step; the more difficult work is proving that previously captured data has actually been removed and that similar collection paths do not exist elsewhere in the product.

For users, the practical lesson is clear: if a coding assistant has access to an entire repository, developers should assume that access may extend beyond the files they think they are sharing. Teams need to verify not just what the product interface says, but what the backend is actually doing.

How does Grok Build compare with other coding tools?

The researchers said the Grok Build behavior was more expansive than that of comparable assistants such as Claude Code. While coding agents frequently need repository context to answer questions or edit files effectively, many tools are designed to minimize collection, avoid persistent retention where possible, and ask for explicit permission before broad access is granted.

The difference is not merely technical. It affects whether a company can use the product in regulated environments, under customer confidentiality obligations, or within internal security policies. A tool that uploads only the file currently under review is easier to justify than one that systematically packages an entire repository into cloud storage.

Why AI coding tools are under pressure now

AI coding assistants are increasingly being sold as productivity engines for developers, but they sit at the intersection of two sensitive domains: proprietary software and machine learning infrastructure. That makes them unusually hard to secure, because they need enough context to be useful without absorbing more data than the user intended to share.

The challenge is growing as coding tools become more agentic. Instead of merely suggesting a line of code, they can inspect files, rewrite projects, generate tests, and interact with build systems. Each of those capabilities raises the stakes around permissions, logging, storage, and retention.

For companies, the core question is not whether an AI tool can help write code. It is whether the tool can do so without creating a new exposure channel for the entire software supply chain.

What should developers and security teams do now?

They should treat AI coding tools like any other third-party service with access to sensitive source code. That means reviewing retention defaults, checking whether the vendor uses repository-wide ingestion, limiting access to secrets, and testing whether “opt out” controls actually stop all data collection paths.

• Audit what files the assistant can read and store.
• Confirm whether data is kept for debugging or model improvement.
• Remove secrets from repositories before using AI tools.
• Use separate test repositories for vendor evaluations.
• Require written security assurances from the provider.

Security teams may also want to insist on telemetry reviews and vendor questionnaires that specifically ask about backup retention, logging, deletion timelines, and whether data is used to train models or to support service reliability.

What does this mean for xAI?

For xAI, the incident is likely to become part of a broader debate about product maturity and trust. The company has been trying to position Grok as a serious competitor in the AI assistant and developer-tool market, but incidents involving hidden data collection can undermine confidence quickly, especially among enterprise users.

Trust is particularly important in developer tooling because the adoption decision is often made by engineers, security staff, and procurement teams together. One serious privacy mistake can delay rollout, trigger internal reviews, or push teams to rival products with more conservative data policies.

That does not mean the issue will permanently damage the product. It does mean xAI will need to do more than promise deletion. The company will have to show clearer controls, better documentation, and a stronger separation between useful context gathering and sweeping repository capture.

Timeline of the Grok Build incident

The sequence of events unfolded quickly once the issue was noticed, then moved into a public response cycle between researchers, reporters, and xAI.

Why the deletion promise may not be the end of the story

Even if xAI deletes the data it knows about, privacy incidents rarely end neatly. Systems can generate logs, caches, backups, replication copies, and administrative snapshots that are not removed by a single command. That is why the claim that uploaded data will be deleted is helpful but incomplete.

Users and security teams will want to know whether deletion includes all internal copies, how long cleanup takes, whether any backups are exempt, and whether the data could have been used during development or troubleshooting before the fix landed. Those are the details that determine whether the incident was a temporary bug or a serious governance failure.

There is also a broader trust issue. If a company says privacy settings are respected, but researchers find a backend behavior that uploads more data than expected, then the user interface and the actual system behavior are out of sync. That gap is exactly what privacy-conscious customers look for when they evaluate whether to adopt a tool.

The bigger picture for AI and code privacy

This episode is part of a recurring pattern in the AI industry. As tools become more powerful, the amount of data they need grows, and so does the chance that sensitive material gets collected, retained, or reused in ways users did not anticipate. Coding assistants are especially vulnerable to this problem because source repositories are dense with operational secrets and proprietary knowledge.

The lesson for the market is straightforward: convenience is not a substitute for control. Developers will adopt AI tools faster when vendors can prove that they collect only what is necessary, store it for clearly defined periods, and give users reliable ways to opt out or purge it entirely.

For now, the Grok Build case is a reminder that “assistant” does not always mean “light-touch.” Sometimes it means broad access, extensive retention, and a privacy policy that matters only if the backend actually follows it.

As AI coding tools continue to spread, companies will face growing pressure to prove that they can improve developer productivity without turning every repository into a data-exposure liability.

Key facts at a glance

• xAI’s Grok Build coding tool was reported to be uploading full repositories to cloud storage.
• The uploads reportedly included files the tool had been told not to open and deleted history.
• xAI disabled the behavior after the issue was reported.
• Elon Musk said previously uploaded data would be deleted.
• Researchers and security experts say the retention level was excessive for sensitive code.

Ultimately, the incident is about more than one coding assistant. It is about whether AI systems handling software development can earn the trust of the people whose most sensitive assets they touch.

Researchers said the problem was not just that the tool used cloud services, but that it appeared to collect and retain far more repository data than developers would reasonably expect.