ZCode Upload Controversy: Did the Code Index Go Out of Bounds?

Zhipu AI’s coding tool ZCode apologized today (September 18) over a controversy involving code repository data uploads. The company confirmed that ZCode’s “code repository indexing” feature could trigger repository data uploads when generating Repo Wiki pages. The feature was enabled by default when it was initially launched, and the issue has now been fixed.

Zhipu stated that once Wiki pages are generated in the cloud, the uploaded data is immediately destroyed and not retained. As follow-up measures, ZCode will open-source its codebase, invite third-party assessors to review how the system operates, and continue publishing updates on the review process. All users will also receive a one-time reset of their weekly usage quota.

The response came relatively quickly, and compensation was offered. But this controversy will not end simply because the company says the data is “immediately destroyed.”

What developers really want to know are several other things: exactly what was uploaded, when it was uploaded, which setting can prevent uploads, and whether the server has the ability to decrypt and read the code. For a programming tool that may access an enterprise’s core repositories, unreleased products, and secret configurations, these are not minor details buried in a privacy policy—they define the product’s security boundaries.

Origin of the Controversy: How Did Local Indexing Turn Into a Cloud Upload?

According to Zhipu’s explanation, the issue stemmed from the “code repository indexing” feature. It was originally designed to generate a local repository index to support session checkpoint recovery, rollback to historical versions, Repo Wiki, and other features.

Three concepts need to be distinguished here:

• Local code indexing: Scanning files, symbols, and dependencies to build a retrieval structure on the user’s device;
• Repository snapshots: Packaging the files or version state at a given point in time to restore task context;
• Cloud-based knowledge base generation: Sending repository content to a server, where a cloud model generates project documentation, module relationships, and Wiki pages.

In theory, the first two can be completed entirely locally. If the third relies on a cloud model, it will likely require uploading source code, code snippets, or processed index data.

The problem is that when users see “code repository indexing,” they typically understand it as something similar to local symbol indexing in an IDE: the tool knows where functions are and which modules depend on one another, but the code does not necessarily leave the computer. Repo Wiki, however, may switch this pipeline from “local analysis” to “cloud processing.” If the product does not clearly explain where the data will go before the feature is enabled, the developer’s mental model will conflict with the product’s actual behavior.

This is also why the feature being “enabled by default” is particularly sensitive. A default is not merely an ordinary UI detail; it represents a risk decision the vendor has made on the user’s behalf. Enabling themes, keyboard shortcuts, or autocomplete by default is generally harmless. Enabling the upload of an entire repository by default—especially one that may include Git history—crosses a reasonable boundary.

Developer Says Snapshot Included Git History, Greatly Expanding the Impact Beyond Current Source Code

The developer who sparked the discussion said they found an encrypted snapshot of approximately 313 MB, along with corresponding status files, in a local ZCode directory. The files reportedly indicated that approximately 345 MB of workspace content had been packaged and that hundreds of upload attempts had failed.

According to the developer’s published investigation, the snapshot involved more than 40,000 files, with .git/lfs, .git/objects, and .git/logs accounting for the vast majority of the space. This suggests that the package may have included more than just the current workspace’s source code. It may also have contained:

1. Old code from historical commits;
2. Files that had been deleted but remained in the Git object database;
3. Large binary assets stored through Git LFS;
4. Local branches, references, and operation logs;
5. Configurations, tokens, or internal addresses that had once been committed and later deleted.

These technical details currently come primarily from an individual analysis and have not yet been publicly verified by an independent security organization, so they cannot be treated as a final audit conclusion. However, they highlight a very real issue: for a code repository, “current files” and “complete Git data” represent entirely different levels of risk.

Many developers immediately delete a file after realizing that they accidentally committed a secret, but forget that the secret may still remain in Git history. Enterprises also commonly store design documents, test data, build artifacts, and even customer samples in LFS. If a snapshot tool simply packages the workspace recursively without excluding .git, dependency directories, caches, and sensitive files by default, the scope of the upload may far exceed what users expect.

In other words, uploading a 300 MB repository is not merely a matter of “transmitting a few extra unnecessary files.” It may carry away years’ worth of accumulated project assets.

“Encrypted Upload” Does Not Mean the Server Cannot See the Data

According to the technical analysis in the disputed article, the ZCode client requests upload credentials and an RSA public key from the server, then uploads a locally generated encrypted archive to object storage. Because the public key is issued by the server, the developer believes the server may possess the corresponding ability to decrypt the data.

This still requires confirmation through a third-party audit, but security cannot be evaluated solely by asking whether the data is encrypted.

Encryption has at least two layers:

• Encryption in transit: Prevents third parties from intercepting data while it travels over the network;
• End-to-end encryption: Only the user holds the decryption key, and the platform cannot read the content.

For an AI coding tool to let a cloud model process code, it can typically only provide the former—or encrypt the data before upload and then decrypt it on the server. This design can reduce the risks of exposure during transmission and in object storage, but it does not prove that the platform cannot access the plaintext.

Therefore, the official claim that data is “immediately destroyed after upload” still requires a more complete technical explanation. At a minimum, it should answer:

• At which processing node the data is decrypted;
• Whether plaintext enters memory, temporary disks, caches, or logs;
• How long ciphertext remains in object storage;
• How long failed uploads and retry tasks are retained;
• Whether the data enters model inference logs, observability systems, or troubleshooting pipelines;
• Whether deletion covers backups, snapshots, and cross-region replicas;
• Which internal roles or service accounts have permission to access the data.

“Not retained” is a product promise, not verifiable proof of security. For personal projects, that statement may be enough; for enterprise code, it is far from sufficient.

Whether Privacy Controls Actually Work Matters More Than Whether They Exist

Another focus of the controversy is the developer’s claim that the existing “Improve Experience” and “Repository Snapshot Indexing” switches could not prevent local packaging or uploads. The company’s response has not yet explained, item by item, how these switches relate to the various background components.

This exposes a common flaw in the permission design of AI coding tools: settings pages are organized around product features, while backend operations are organized around technical components.

A user may disable “Wiki” or “Improve Experience,” while the backend may still run another component called snapshotting, checkpointing, memory, or task recovery. From the developer’s perspective, all of these components are reading the same code. From the product team’s perspective, however, they are separate features, so a single switch may not cover every data egress path.

A trustworthy programming tool should provide at least three levels of control:

1. Workspace-Level Master Switch

Users should be able to explicitly choose between “local processing only” and “allow cloud processing.” Once cloud processing is disabled, no component should upload repository content—not merely disable one page-level feature.

2. File List Before Upload

Before the first upload, the tool should display the number of files, total size, exclusion rules, and reason the upload was triggered. High-risk content such as .git, .env, certificates, keys, and database files should be rejected by default or require secondary confirmation.

3. Auditable Data Egress Logs

The tool should provide a firewall-like log page explaining what was uploaded, when it was uploaded, where it was sent, which task it was used for, and when it was deleted. Developers should not have to capture network traffic or reverse-engineer the client just to determine whether their code has left their computer.

If privacy controls exist only in UI copy but cannot constrain the underlying task scheduler, those controls are effectively meaningless.

What Zhipu Got Right in Its Response—and What Was Missing

Objectively speaking, Zhipu acted relatively responsibly by quickly confirming the issue after the controversy emerged, publicly apologizing, and promising to open-source the product and introduce third-party reviews, rather than vaguely attributing the matter to “user misunderstanding.”

Open-sourcing the client is particularly important. It allows the community to inspect file traversal rules, exclusion lists, upload trigger conditions, key exchange methods, and whether background tasks continue to run after a feature is disabled. For developer tools, inspectable code is often more convincing than an updated privacy policy.

But open source is not a universal solution.

If only the client is open-sourced while the server-side upload API, data-processing pipeline, logging system, and deletion mechanisms remain opaque, outsiders can at most verify “what the client sent,” but not “what the server did after receiving it.” If the open-source version cannot be matched to the officially distributed installer through reproducible builds, there is also no way to prove that the binary users are running corresponds to the published source code.

The upcoming third-party review should cover at least the following:

• Consistency between the official installer and the open-source code;
• The complete trigger matrix for Repo Wiki, snapshot, and checkpoint features;
• Default exclusion rules and how they have changed across versions;
• Server-side decryption, inference, caching, and deletion processes;
• Object storage permissions and access logs;
• Whether historically uploaded data has in fact been deleted;
• Whether privacy controls work across different login states, versions, and operating systems.

The review report should not merely state that “no significant risks were identified.” Developers need reproducible steps, version numbers, the review’s time range, and a list of issues that have been fixed.

This Is Not Just a ZCode Problem

AI coding products are evolving from tools that “complete the current line” into agents capable of operating across an entire repository. To perform cross-file refactoring, resume long-running tasks, automatically generate documentation, and enable remote takeover, these tools inevitably need to index more data—and are therefore more likely to send local code to the cloud.

Claude Code, Codex-like products, and various IDE agents all face the same challenge: the more capable they become, the more context they need to read; the more context they read, the harder it becomes to explain the data boundaries.

The permissions of traditional IDE plugins are relatively straightforward: read files, access the network, and execute commands. An Agentic Development Environment, by contrast, chains these capabilities into an automated workflow. A routine conversation may trigger directory scanning, Git status reads, file compression, vector indexing, model inference, and task snapshotting in the background.

AI coding tools therefore cannot continue using the authorization logic of consumer applications. A code repository is not a photo album, and Git history is not an ordinary cache. They may contain trade secrets, vulnerability information, customer data, and software supply-chain credentials.

From the perspective of industry standards, the reasonable baseline should be:

• Cloud-based code processing must be explicitly opted into rather than enabled by default;
• Local indexing and cloud indexing must use different names and separate controls;
• .git, key files, and user-designated sensitive paths must be excluded by default;
• The scope of uploads and their intended use must be visible before the operation;
• Enterprise versions should support on-premises deployment, customer-owned object storage, and customer-managed keys;
• When a product update changes how data is processed, user authorization should be obtained again.

What Developers Should Do Now

Before the results of a third-party audit are made public, developers using ZCode or other repository-level AI tools can take several steps to review their exposure:

1. Upgrade to a version that the vendor has confirmed contains the fix, and do not continue using a client released before the controversy;
2. Inspect local cache and snapshot directories to check for unusually large archives, status files, or records of continuous retries;
3. Monitor network connections to determine whether the tool is uploading large amounts of data to object storage, logging platforms, or unknown domains;
4. Rotate any secrets that may have entered Git history, including API keys, cloud service credentials, database passwords, and signing certificates;
5. Create separate test repositories for sensitive projects, rather than giving production repositories directly to agents that have not completed a security assessment;
6. Review enterprise compliance terms to determine whether code may be used for model training, log analysis, or product improvement;
7. Establish team-level egress policies by using proxies, firewalls, or endpoint management tools to restrict uploads to unapproved destinations.

It is especially important to note that deleting a local cache does not mean cloud data has been deleted. Disabling a UI switch also does not necessarily mean that every background component has stopped. For core repositories, the safest approach remains to wait for verifiable audit findings or use a solution that explicitly supports fully local processing or on-premises deployment.

A One-Time Quota Reset Cannot Repair the Trust Gap

Zhipu’s additional one-time reset of the weekly quota for all users is primarily a product operations measure. For ordinary users, it may count as a gesture of goodwill. For a data incident that may involve enterprise source code, however, it does not address the core issue.

The value of this controversy is that it has brought the seemingly ordinary feature of “code indexing” back under security scrutiny. AI coding tools like to emphasize that they can understand an entire repository, but they rarely explain with equal clarity where that understanding takes place.

Whether ZCode deserves continued trust will not depend on how much usage quota it gives away, but on three things: whether the open-sourcing is complete, whether the audit is verifiable, and whether the default settings are genuinely changed to minimize data collection.

The same applies to the industry as a whole. Allowing an agent to read code does not mean consenting to have that code packaged and uploaded. Allowing a cloud model to answer questions does not mean authorizing the platform to take possession of the complete Git history. Only vendors that can define this boundary clearly and operate transparently deserve a place in an enterprise’s core development workflow.

References

• ITHome: Zhipu ZCode Accused of “Secretly Uploading Code”; Company Says the Issue Has Been Fixed — Includes Zhipu’s response regarding code repository indexing, Repo Wiki data uploads, the issue’s resolution, and its plans for open-sourcing and subsequent reviews.