ZCode Git History Upload Turns a Coding Convenience Into a Trust Problem

ZCode allegedly uploaded an entire 345 MB developer workspace, including its Git history, despite settings that appeared to limit data collection. The reported ZCode Git history upload was not restricted to files selected for an AI prompt. It included repository objects, reflogs, and cached large files that could preserve years of private engineering work.

A technical investigation published on September 18 traced the behavior through ZCode’s closed desktop application. According to that analysis, the client created encrypted workspace checkpoints and transferred them to Alibaba Cloud Object Storage Service while the user was signed in.

The finding remains a third-party reverse-engineering claim, not an independently audited disclosure from Z.ai. At publication time, the available official materials did not clearly explain the reported upload scope, checkpoint retention, or how users could prevent it.

That verification gap is part of the story. ZCode promotes GLM models with an agent designed to understand a workspace, execute commands, and recover long-running tasks. However, an open-weight model does not make the surrounding desktop application transparent.

The central conflict is therefore not ZCode versus another coding assistant. It is the product’s visible privacy controls versus the behavior attributed to its hidden checkpoint system.

What the ZCode Git History Upload Report Found

The investigation claims ZCode captured a repository archive, not merely the code needed for one model request.

The researcher examined a private commercial workspace containing 42,411 files. The original directory occupied roughly 345 MB, while ZCode’s encrypted checkpoint was approximately 313 MB.

The reported contents were especially revealing. About 196.1 MB came from the .git/lfs directory, where Git Large File Storage can cache large project assets. Another 102.2 MB came from .git/objects, Git’s underlying database of file contents, directory trees, and commits.

Reflogs added approximately 0.6 MB. Current source files, configuration, and documentation represented about 46.2 MB, or 13.4 percent of the measured material.

In that individual snapshot, the .git directory accounted for 86.6 percent of the archived data. That does not establish an average across all ZCode installations. It does show why calling the event a routine code upload understates the reported scope.

The original account says ZCode created the checkpoint under its local application data and left a plaintext manifest beside the encrypted archive. That manifest reportedly exposed the absolute path of the affected workspace.

According to the reverse engineering, ZCode requested upload credentials from a Z.ai service. The response included an object key, a signed upload form, a size limit, and an RSA public key.

The client allegedly compressed the workspace, encrypted it with AES-256-CTR, and wrapped the symmetric key using RSA-OAEP-SHA256. It then posted the encrypted object directly to an Aliyun storage endpoint.

A callback reportedly informed Z.ai’s backend after the transfer completed. If that reconstruction is correct, the upload was a designed application flow rather than an accidental model request containing too much context.

Encryption does not resolve the disclosure problem. It protects data from observers between the computer and the storage service, assuming the implementation is correct. It does not prevent the intended service operator from accessing the information.

The report says the matching RSA private key remained under server control. Consequently, the user who supplied the repository could not decrypt and inspect the checkpoint stored on the same computer.

This distinction matters. “Encrypted” can sound like “unavailable to the vendor,” but those statements are not equivalent. Encryption protects data according to who controls the relevant keys.

The report also claims that two visible privacy settings did not stop checkpoint creation or transfer. That allegation has not been confirmed through an independent product audit, and one Hacker News participant reported finding no corresponding checkpoint directory.

The difference could reflect product versions, operating systems, account states, staged deployment, or specific feature use. It could also indicate that the original case does not apply to every user.

Z.ai needs to clarify those conditions. Until then, the safest description is that researchers documented the behavior in at least one tested environment, while its full prevalence remains unknown.

Why a Full .git Directory Is More Sensitive Than Today’s Code

A Git repository contains a project’s memory, including information that no longer appears in its current files.

Developers often describe .git as “history,” but it contains more than the output of git log. It stores objects, references, branch information, configuration, reflogs, and other repository metadata.

Git is fundamentally a content-addressable database. Its blob objects preserve file content, tree objects describe directory states, and commit objects connect snapshots into history.

The official Git object model explains how those elements remain inside .git/objects. An application that copies that directory can receive far more than the files visible in the working tree.

Consider a developer who accidentally commits an API credential on Monday and removes it on Tuesday. The current file no longer displays the credential, but the earlier object can remain reachable through repository history.

Deleting the latest copy is not enough. GitHub’s guidance on removing sensitive data tells developers to revoke exposed credentials first, then consider a coordinated history rewrite.

The same issue applies to private certificates, internal hostnames, customer identifiers, environment files, and credentials embedded in test fixtures. A repository can also retain abandoned architecture, security fixes, unreleased products, and licensing material.

Reflogs extend the risk. They record how local references moved and can preserve access paths to commits that are no longer visible on a shared branch.

Local branches may reveal initiatives that were never pushed. Commit messages can name clients, vulnerabilities, employees, or internal incidents. Repository configuration can identify private remotes and infrastructure domains.

Git LFS introduces another category. Its cache can contain design files, datasets, media, packaged models, or other binaries that developers reasonably believe are outside an assistant’s immediate context.

The reported 196.1 MB LFS component was therefore not unimportant bulk. It could represent some of the project’s least text-like and most commercially sensitive material.

A coding agent may legitimately need broad local access. It cannot refactor a complex application without reading related modules, running tests, or understanding dependencies.

That local permission does not automatically imply permission to create a durable cloud copy of everything accessible to the process. Reading a file for a requested task, sending selected context for inference, and archiving the full repository are separate operations.

This is why the ZCode Git history upload claim is more serious than the observation that cloud coding assistants process code. The dispute concerns scope, persistence, control, and disclosure.

A developer might knowingly approve a model request containing a function and its dependencies. That same developer might reject uploading an LFS cache, deleted credentials, dormant branches, and years of commit objects.

Enterprise users face additional concerns. A repository can contain material governed by customer contracts, source-code escrow terms, export controls, data residency rules, or employee access policies.

The relevant question is not simply whether encryption was used. Security teams need to know what was collected, where it was stored, who held the keys, how long it remained, and how deletion worked.

Privacy Controls and Checkpoints Appear to Tell Different Stories

The sharpest concern is the reported gap between what users could control and what the application allegedly did.

ZCode’s official documentation describes an agent that understands workspace state, file references, tasks, and Git branch context. Its agent documentation also presents state recovery as part of supporting longer development tasks.

Checkpointing can serve a legitimate purpose. An agent that edits dozens of files needs a way to recover after a failed change, compare states, or restore work interrupted by a crash.

That function does not require checkpointing to be invisible. Nor does it establish that every part of .git must be included in a remote archive.

A privacy-preserving design could exclude Git objects and LFS caches by default. It could publish the exact archive manifest before transfer, keep checkpoints local, or request explicit approval before cloud synchronization.

It could also provide an organization policy that blocks remote snapshots. Administrators could enforce repository-level exclusions and confirm their effect through an audit log.

The investigation instead alleges that ZCode’s archive process operated outside the agent’s visible tool loop. The agent’s listed tools reportedly contained no snapshot or upload action that users could approve.

That architecture would explain why command permissions failed to stop the transfer. A host-level sidecar can run independently from the model’s tools, even when the user restricts shell execution or file modification.

It also exposes a blind spot in current agent interfaces. Permission prompts usually focus on conspicuous actions, such as running a command, editing a file, or opening a network address.

Background services receive less attention. They can index folders, collect diagnostics, synchronize sessions, or create recovery artifacts without appearing in the conversation.

The distinction between inference and synchronization becomes important here. Sending selected code to a cloud model is visible enough that most users expect it from a cloud-backed assistant.

Copying the underlying repository database for rollback or indexing is a second data flow. It needs its own explanation, scope controls, retention rules, and deletion interface.

ZCode’s current privacy policy says personal data can be retained as needed to provide services, meet obligations, protect legitimate business interests, and improve safety or stability. It also says retention varies with data type, sensitivity, purpose, and legal requirements.

Those general statements do not answer the questions raised by the report. The policy needs to identify whether workspace checkpoints count as user input, technical data, or another category.

It should also explain which storage region applies, whether subcontractors process the archives, and whether deletion of an account removes every checkpoint. Users need concrete retention periods or clear criteria tied to the relevant feature.

Most importantly, Z.ai should document whether privacy toggles affect checkpoint uploads. A control labeled around data collection can create false confidence if it governs analytics but not workspace synchronization.

The language and placement of a control matter as much as its internal implementation. Developers cannot make informed decisions when materially different data flows are grouped behind vague terms.

The strongest possible response from Z.ai would be technical, not rhetorical. It would list affected versions, activation conditions, archive exclusions, endpoints, encryption roles, retention periods, and deletion procedures.

It would also explain whether the behavior changed after the report. Without that detail, users cannot determine whether an update fixed the issue or merely removed local evidence.

Open Weights Do Not Make a Closed Coding Agent Local

The incident separates the model from the software that decides what the model can see and what leaves the machine.

GLM models are central to Z.ai’s developer strategy, and some releases have been distributed with open weights. Developers can inspect those model files, run compatible versions on their own infrastructure, and avoid a hosted inference endpoint.

ZCode is a different layer. It is the harness that chooses context, invokes tools, stores sessions, manages checkpoints, connects to cloud services, and updates itself.

The harness can determine privacy outcomes even when the underlying model runs locally. A local model does not prevent a surrounding application from sending telemetry, indexes, session history, or recovery snapshots elsewhere.

Likewise, an open model cannot expose what a closed Electron application does in a background process. Researchers must observe network traffic, inspect application bundles, and reconstruct behavior after release.

This is the primary trust conflict. ZCode’s product experience emphasizes local workspace understanding, while the report describes a cloud capture mechanism broader than developers expected.

Competitors also process developer data, so the right comparison is not “ZCode uploads code while every other agent stays local.” That would be inaccurate.

Claude Code, GitHub Copilot, Codex, Cursor, and other cloud-connected tools send some user inputs and code context to remote services. Repository indexes, agent sessions, and cloud task environments can create additional copies.

The differences appear in disclosure and control. GitHub, for example, documents content exclusion policies and explains that some Copilot surfaces do not support those exclusions.

GitHub also documents when semantic indexing for repositories outside GitHub uploads data and states that enterprise administrators must enable that feature. Those controls still have limitations, but users can identify the data flow and evaluate it.

That is the standard Z.ai now faces. A vendor does not need to promise that no code ever leaves a computer if the product depends on cloud inference.

It needs to describe each transfer accurately. It must distinguish temporary prompt context from a persistent repository snapshot and give administrators enforceable control.

Open-source harnesses offer one response. Their code can reveal archive exclusions, network endpoints, and update behavior, while independent reviewers can test whether documented settings match implementation.

Open source is not a complete security guarantee. Few users inspect every dependency, signed binaries can differ from published code, and compromised updates can still cause harm.

Closed-source tools are not automatically malicious either. They can undergo independent assessments, provide detailed data maps, enforce tenant controls, and publish verifiable network behavior.

However, opacity raises the cost of verification. When an application has broad filesystem permissions and autonomous execution, that cost becomes a material security consideration.

The discussion on Hacker News reflected both sides. Several commenters treated any closed coding harness as an unacceptable risk, while others noted that cloud agents inherently receive project context.

One user said they could not reproduce the reported checkpoint directory despite using ZCode. Others argued that a sandbox should constrain every proprietary developer tool, regardless of vendor or country.

Those reactions identify two different responsibilities. Vendors must disclose their data flows, and development teams must limit what an agent can reach.

Neither responsibility cancels the other. Sandboxing is not consent, and a privacy control is not effective containment.

The Immediate Risk Depends on Repository Content and Product Version

The evidence supports urgent review, but it does not prove that every ZCode user had the same data uploaded.

The documented example involved one workspace and one observed application configuration. Public reporting has not established how many installations created checkpoints, when the behavior began, or whether every operating system followed the same path.

It is also unclear whether users had to enable a particular recovery or indexing feature. Authentication state may matter because the report associates transfers with being signed in.

Version history matters too. A later release could change the directory, endpoint, exclusions, or scheduling behavior without invalidating the earlier observation.

This uncertainty should narrow claims, not suppress investigation. Teams that used ZCode with private repositories have enough evidence to conduct an incident review.

They should begin with scope. Identify which developers installed ZCode, which versions they ran, when they signed in, and which repositories were accessible during those periods.

Next, inspect endpoint, proxy, DNS, firewall, and endpoint-detection logs for communications with Z.ai and Aliyun services. Local checkpoint files may help, but their absence does not conclusively establish that no transfer occurred.

Organizations should preserve evidence before uninstalling or updating the application. An update can modify logs, storage paths, or binaries that would otherwise help investigators reconstruct activity.

Security teams should assume any credential committed to an exposed repository’s history needs review. GitHub recommends rotating a leaked credential because removing it from the latest files does not neutralize it.

That response should remain proportionate. Do not rotate every corporate credential solely because one developer installed ZCode. Map the repositories first, then search their histories and validate which secrets remained active.

Repository owners should also examine sensitive non-secret material. Old commits might contain customer data, vulnerability details, internal endpoints, licensed assets, or negotiations that require legal review.

If the repository contained regulated or contractually restricted data, counsel and compliance teams should evaluate notification obligations. The answer depends on jurisdiction, contract language, confirmed transfer evidence, and the data involved.

Developers who continue testing ZCode should isolate it. A dedicated virtual machine or container can limit the visible filesystem, although networking and mounted directories still require careful configuration.

Use a disposable repository containing no real credentials or commercial history. Avoid mounting a home directory, SSH folder, cloud configuration, package credentials, or unrelated source trees.

Filesystem restrictions can block checkpoint directories, but they are a brittle defense. Paths and processes can change across updates, and denying writes can disable recovery behavior or break the application.

Network controls offer another layer. Teams can restrict outbound destinations and record attempted connections, though blocking required services may make the product unusable.

A safer long-term model uses explicit allowlists. The agent receives a narrow project checkout, temporary credentials, and only the services required for the task.

This approach is useful across engineering workflows, not only with ZCode. Any autonomous assistant with filesystem and shell access should be treated as a privileged development dependency.

The goal is not to prove malicious intent from incomplete evidence. It is to reduce the consequence of undocumented behavior.

Three Signals Will Show Whether Z.ai Has Resolved the Trust Gap

The next test is whether Z.ai turns an undocumented data flow into a narrow, visible, and verifiable product feature.

The first signal is a detailed public response. Z.ai should confirm or dispute the reported ZCode Git history upload, identify affected versions, and explain which product state triggered it.

A useful statement would address the measured archive contents directly. It should say whether .git/objects, .git/lfs, reflogs, ignored files, and global configuration were included.

If Z.ai publishes only a general assurance that data is encrypted, the central concern remains. The company reportedly controlled the decryption key, so transport encryption does not answer questions about access or retention.

The second signal is an enforceable checkpoint control. ZCode needs a setting that stops remote snapshots, can be managed by an organization, and is independent from analytics or model-training preferences.

Users should be able to verify the setting through logs or a documented network event. The application should show what it intends to upload before the first transfer.

Default exclusions should remove .git, LFS caches, ignored files, credentials, and common secret locations. Users could opt in to additional history when a task genuinely requires it.

A local-only recovery option would resolve much of the tension. Checkpoints can support rollback without becoming cloud archives, particularly when the agent and model run on the same machine.

The third signal is independent reproduction. Researchers need to test a current release across supported operating systems, new and existing accounts, and different privacy configurations.

That work should answer whether the original behavior was universal, conditional, or already changed. It should also verify whether deleting checkpoints through the product removes every server-side copy.

A third-party assessment would strengthen Z.ai’s response, especially if the assessor publishes the scope and methods. Reproducible packet captures and archive manifests would be more valuable than broad certification language.

For development teams, the lesson reaches beyond one application. Inventory coding agents as software supply-chain components, document their endpoints, and review their data flows before granting access to private repositories.

Ask five direct questions: What can the agent read? What does it transmit? What persists remotely? Who holds the keys? Which control stops each transfer?

If a vendor cannot answer those questions, restrict the agent to disposable environments until it can. If an answer relies only on “encrypted,” ask who can decrypt it.

The reported ZCode Git history upload has not yet established the exposure of every user or proven misuse of any archive. It has established a credible mismatch that demands a precise response.

Z.ai can narrow that gap by publishing the mechanism, fixing the defaults, offering a real off switch, and supporting independent verification. Until then, developers should treat ZCode’s visible workspace as the minimum possible collection boundary, not the maximum.