Twice in ten weeks, an AI coding tool was caught uploading entire repositories. The second fix shipped as a one-line bug note.

Someone was freeing up space on a MacBook Air. They noticed a hidden folder, ~/.zcode, holding more than 700 MB. Inside it, under v2/checkpoints, was a 313 MB encrypted file with a small metadata record beside it. The record had a field called failureCount, and the number in it was 564.

Five hundred and sixty-four attempts to upload something, none of which had been mentioned to them.

The something was their workspace. A commercial project, 42,411 files. And 86.6 percent of the compressed payload was not the source code. It was the .git directory: the complete version history of the project, every commit ever made, every file ever deleted, every branch never pushed.

They could not open the archive to check. The encryption key had been wrapped with a public key supplied by the server, and the matching private key never touches your machine.

Everything below was checked against primary sources on September 20, 2026. Where a claim comes from a researcher rather than from a vendor page or an API, it is attributed to that researcher, and where we could not confirm something we say so. The vendor changelog quotations are pulled verbatim from the published changelog, the privacy policy dates come from the policy itself, and the GitHub facts come from the repositories.

What was found

The original write-up is by a developer publishing as ferstar, dated September 18, 2026, titled “Inside ZCode: Silently Uploading Your Entire Git History to the Cloud.” ZCode is the desktop coding agent from Z.ai (the international brand of the Chinese AI company Zhipu), paired with the GLM family of models. Secondary accounts date its launch to July 2026; we note that the public changelog only goes back to version 3.10.1 on August 28, so we cannot confirm that from the vendor’s own records. It is an Electron application, which is why the investigation was possible at all: ferstar unpacked app.asar and traced the pipeline.

The mechanism he describes:

1. A background component packages the workspace into a tar archive. The rule that includes .git sits before the exclusion rules, so history is captured first and filtered never.
2. The client asks zcode.z.ai for upload credentials via POST /api/v1/snapshot/upload-credential.
3. The server returns a form signature for Alibaba Cloud object storage plus a fresh RSA public key.
4. The client encrypts the archive with AES-256-CTR, wraps that symmetric key with RSA-OAEP-SHA256, and posts the result straight to the storage nodes.
5. Object storage calls back to the Z.ai backend to register the snapshot.

This is textbook envelope encryption, and it is competently done. It is also one-directional. The person whose code it is cannot decrypt their own archive. Only the vendor can.

The same day, September 18, a second developer reproduced the finding independently on his own machine. Feng Ruohang, who publishes as Vonng and is known in the Postgres world for the Pigsty distribution, examined ZCode 3.12.3 on macOS and found snapshot records for four separate workspaces:

Workspace	Plaintext	Encrypted	Status
silo	229 MB	211 MB	credentials issued, upload pending
mc	232 MB	229 MB	credentials issued, upload pending
pgnls	405 MB	7.4 MB	upload accepted and completed
pgdoc	1.53 GB	1.07 GB	rejected for size, 102 failures

In the silo snapshot, .git accounted for 93.9 percent of the bytes and 8,323 of 9,619 files, including dangling objects and git-filter-repo metadata. That last detail is worth sitting with. filter-repo is the tool you run when you need to scrub something out of a repository’s history. Its leftovers being in the archive means the pre-scrub objects were candidates for the ride too.

The toggles that did not do the thing

ZCode has two switches in its interface that a reasonable person would read as covering this.

• Optimize Experience, internally optimizeAgentExperienceEnabled
• Repo Snapshot Indexing, internally repoSnapshotIndexingEnabled

Per ferstar’s reading of the code, the first governs only whether data is authorized for model training, and the second governs only whether the server indexes what it already has. Neither one is checked on the path that packages and uploads. The capture component starts unconditionally whenever the app is running with a valid login.

Vonng tested the claim rather than reading it. His logs recorded the snapshot indexing setting as false 1,339 times between September 13 and 18. Snapshots were written throughout. He also reports finding no local environment variable that disables the behaviour, and concludes that the decision is made server-side: the client asks for credentials, and the server decides whether to hand them over.

If that reading is right, then it is not a setting at all. It is a request, and the answer is not yours to give.

Why .git is the part that should worry you

Most people, told that a tool uploaded their code, think about the code. The code is usually the least sensitive thing in the archive.

A .git directory is not a copy of your project. It is every copy of your project that has ever existed, plus the commentary. Concretely, it contains:

• Files you deleted, in the state they were in before you deleted them. The .env that was committed in week one and removed in week three is still there. Deleting a file in git adds a commit; it does not remove the blob.
• Credentials you already rotated. Rotation fixes the live system. It does nothing to the history, which still contains the old value and, more usefully to an attacker, the shape of your naming and the services you use.
• Every branch you never pushed. The half-finished migration, the experiment with a competitor’s API, the branch named after a client who asked you not to name them.
• Commit messages. Which are, in most shops, an unfiltered internal log: ticket numbers, client names, “temporarily disable auth check for the demo,” the name of the person who broke the build.
• The reflog, which records where every branch pointer has been, including the commits you thought you had abandoned.

You can see the scale of this on your own machine in two commands:

du -sh .git
git rev-list --objects --all | wc -l

On a modest project the second number is usually in the thousands. On a five-year client codebase it is often in the hundreds of thousands, and the first number is larger than the working tree you are looking at.

Chengming Technology, a Chinese company that went on to send Zhipu a legal letter over this (more below), says the material it found in its own uploads included “full project source code, system architecture, version control history, database passwords, cloud service credentials, and employee personal information,” across a workspace of 32,932 files and roughly 411 million characters of plaintext. That list is not surprising. That list is what a .git directory contains on an ordinary Tuesday.

This is the same problem we covered when Vite dev servers were found serving .npmrc and .env to anyone who could reach them and when Stripe keys started turning up in exposed environment files. The failure mode is identical: a secret that was only ever supposed to exist in one place turns out to exist in several, and the extra copies are the ones nobody inventories.

What the vendor said, and what the changelog said

Z.ai responded quickly. A statement went out on September 18 (multiple accounts put it at 17:44 local time), and translated, its substance is:

The issue stems from ZCode’s “codebase indexing” feature. This feature is meant to help users generate a repository index locally, which supports session checkpoint restoration, rolling back to past versions, and Repo Wiki, among other things. When the Repo Wiki feature generates Wiki pages, it may trigger an upload of repository data. After the Wiki pages are generated in the cloud, the uploaded data is destroyed immediately and is not stored. Because this feature was enabled by default in its early launch period, some users were affected. We sincerely apologize for this. The issue has now been fixed.

The statement also promised to open-source the codebase and invite third-party review, and granted every user an extra weekly quota reset, issued the same day.

As apologies from AI companies go, this one is comparatively direct. It names the feature, admits the default, and does not blame the researcher. Three things about it are still worth flagging.

First, “destroyed immediately” is unfalsifiable from the outside. There is no mechanism by which a customer can verify deletion of an archive they were never told about, encrypted with a key they do not hold, sitting in storage they cannot enumerate. That is not an accusation that it is untrue. It is an observation that the claim carries no evidence with it, and the whole reason this became a story is that the product’s observable behaviour and its stated behaviour had already diverged once.

Second, the fix arrived as a bug-fix line. We pulled the official changelog at zcode.z.ai/en/changelog directly. Release 3.14.0, dated September 19, 2026, lists eleven new features and sixteen bug fixes. Here is the entry that covers this incident, verbatim and in full:

Fixed an issue with abnormal uploads in the repository wiki

That is the whole record. A user reading the changelog to decide whether to update would have no way to tell that line apart from the one three rows down about a plugin update badge not displaying fully. The same release notes, incidentally, also announce that “The approval dialog now supports directly granting full access.”

The previous release, 3.12.3, dated September 17, does not mention it at all. Chengming’s letter asserts that upload activity was still observed in the early hours of September 18, after that version shipped.

Third, the promised open-sourcing has not happened yet. As of today the zai-org GitHub organization contains zcode-plugins (the plugin marketplace, last updated September 17) and feedback (a suggestions repository, last updated August 17). There is no repository containing the ZCode client. That is not a broken promise, because “in the near future” has not expired. It is simply the current state, and it is checkable, which is more than can be said for the deletion claim.

We also read Z.ai’s developer privacy policy. It is published at docs.z.ai/legal-agreement/privacy-policy and carries Last Update: September 29, 2025. Its description of user content is:

User Content. This includes any text prompts, images, or other data you input. This information is processed in real-time to provide you with the Service.

“Data you input” is doing heavy lifting there. Nobody inputs a reflog. The policy also states:

We generally provide the Services from Singapore, and our group companies and their designated service providers are typically located in Singapore. As a result, your personal data is generally processed in Singapore.

The observed destination was Alibaba Cloud object storage. We could not determine the region of those nodes from the outside, and neither could the researchers, so we are not going to claim a jurisdiction was breached. What we can say is that the policy describes a general posture rather than a location for this specific pipeline, because this specific pipeline is not in the policy at all.

Where the honest uncertainty is

We do not think everyone who installed ZCode had a repository uploaded, and it would be sloppy to imply it.

At least one long-time user reported publicly that they have no ~/.zcode/v2/checkpoints directory at all and can find no capture or upload activity in their logs. A follow-up suggestion in the same discussion was that the behaviour tracked account tier, with free accounts affected and paid ones not. We could not confirm that, and nobody has published a systematic sample. The honest summary is: two independent investigators found it on their machines, at least one user did not find it on theirs, and the population-level answer is unknown.

One more caution, because it affected the early coverage. A widely shared English write-up of this story turned out to be a machine paraphrase of ferstar’s original post, and it introduced errors, including conflating “git history” in the sense of git log output with the .git directory. Those are wildly different in size and sensitivity. If you go looking for sources on this, go to ferstar’s post and Vonng’s post, both linked at the end, and treat the aggregator versions as what they are.

This is the second time in ten weeks

The reason to write this up is not that one vendor shipped one bad default. It is that this is now a pattern with a repeatable shape.

On July 12, 2026, a researcher published wire-level evidence that xAI’s Grok coding agent was packaging users’ directories, git bundles and all, and uploading them to cloud storage the company controlled. One affected user’s public account of what went up included SSH keys, a password manager database, documents, photos and video. xAI turned default retention off the same day and said previously retained coding data would be deleted.

On July 15, 2026, three days later, xAI open-sourced the agent. The repository xai-org/grok-build is live today under the Apache 2.0 licence: Rust, 26.9k stars, 47 commits on the main branch. It was published as a fresh history rather than the real one, which is its own small irony, but it is genuinely there and genuinely inspectable.

Line the two up:

	Grok agent, July 2026	ZCode, September 2026
What went up	Directories including git bundles, keys, personal files	Workspace archives, .git dominant by volume
Discovered by	Independent researcher, wire capture	Independent researcher, disk usage
In the privacy policy beforehand	No	No
Working opt-out at the time	Retention default was on	Two toggles, neither on the capture path
Vendor response	Apology, retention off, deletion promised	Apology, feature fixed, deletion claimed
Open-sourced afterwards	Yes, 3 days, Apache 2.0	Promised, not yet published
Compensation	Usage limits reset	Extra weekly quota reset

Two vendors, ten weeks apart, arrived independently at the same playbook: apologize, promise deletion, open-source the client, hand out free credits. The convergence is not a coincidence. It is what happens when a product category has a structural incentive to hoover up repositories (server-side indexing genuinely does make these tools better) and no structural incentive to tell you.

We wrote in our piece on agent sandbox escapes that the interesting risk in agentic tooling is not the model deciding to do something bad. It is the surrounding software doing something ordinary that nobody wrote down. Both of these incidents are that. Neither involved a model misbehaving. Both involved a background uploader behaving exactly as designed.

The part where it becomes a business problem

On September 20, Taiyuan Chengming Technology sent a formal letter to Beijing Zhipu Huazhang Technology, reported the same day by Chinese tech press. It is the first instance we are aware of where this moved from a community complaint to a corporate demand, and the demands are instructive because they are the questions any customer should be able to ask:

• Stop processing and delete all uploaded data, derivatives, caches and backups
• Provide a complete list of what was processed
• State where the data went, and whether it was shared with third parties
• State whether it was used for model training
• State whether cross-border transmission occurred
• Explain how the encryption keys are managed
• Provide proof of deletion
• Name the responsible entity for data exports

Written reply demanded before October 10. As of this writing there is no public response.

Notice that almost none of those questions are technical. They are the questions a client asks you when your tooling touched their code.

That is the part that turns this from an interesting story into an invoice. If you are a development shop, an agency, or a freelancer, the code on your machine is frequently not yours. It belongs to a client, and somewhere in the contract you signed there is a confidentiality clause, and quite possibly a subprocessor clause that requires you to name every third party that processes their material. A background uploader you did not know about is a third party you did not name.

Canada put this in writing on September 10

Ten days before any of the above, the Office of the Privacy Commissioner of Canada published draft guidance titled Guidance on assessing third-party service providers, released September 10, 2026, open for comment until December 4, 2026.

The legal backdrop has not changed: under PIPEDA’s accountability principle, an organization remains responsible for personal information in its possession or custody, including information transferred to a third party for processing, and is expected to use contractual or other means to ensure a comparable level of protection. That has been the rule for years.

What the new draft adds is a list of what due diligence is supposed to look like before you sign. Summarizing the OPC’s recommended practices:

1. Identify what personal information is involved, including anything sensitive
2. Map how data flows between the parties
3. Confirm each purpose the provider will use it for
4. Evaluate the technology for risks, including vulnerabilities
5. Understand subcontractor involvement, in writing
6. Assess the risk where processing happens outside Canada
7. Do diligence on training data sources
8. Verify security practices and breach management
9. Assess vendor lock-in and lock-out
10. Confirm retention and deletion procedures
11. Establish ongoing monitoring

Read that list against the ZCode timeline. Item 5 fails when the storage subcontractor is not disclosed. Item 6 fails when you cannot determine the region. Item 10 fails when deletion is asserted rather than evidenced. Item 11 fails by definition when the behaviour was undocumented.

It is a draft, and drafts are not law. But the OPC publishing this in the same month as the second repository-upload incident of the quarter is a fair signal of where the expectation is heading. If you handle client data in Canada, this is the checklist your client’s lawyer will eventually be holding. Our earlier piece on Canada’s privacy reform and what it means for a small business covers the statutory side; this guidance is the operational side of the same obligation.

What the careful tools actually do, for comparison

It would be dishonest to leave the impression that every AI coding tool is doing this, or that sending code to a server is inherently the scandal. Of course these tools send code to a server. That is how a remote model reads your file.

The distinction that matters is between data you sent as part of a request and data a background process collected on its own. Here is how two widely used tools document themselves, from their own pages.

Cursor does maintain a server-side index of your codebase, and says so openly. Its data-use page, last updated September 3, 2026, describes uploading code in chunks to compute embeddings, discarding the plaintext after each request, and retaining obfuscated embeddings and metadata rather than source. With Privacy Mode enabled it states zero-retention arrangements with model providers and no training on your code. You may or may not accept that trade. The point is that it is written down before you agree to it, which makes it a decision rather than a discovery.

Claude Code documents its telemetry as excluding code, prompts and file paths, with error reports scrubbed of known secret patterns before leaving the machine, and provides DISABLE_TELEMETRY=1 and DISABLE_ERROR_REPORTING=1 as environment variables. Under commercial terms, code sent to it is not used to train models by default.

Neither of those is a security guarantee, and neither exempts a vendor from being checked. But both describe a background data path, publish an off switch, and honour it. Those are the three things ZCode’s disclosed behaviour was missing on all counts.

The general rule we would offer: a harness that cannot tell you what it sends is a harness you cannot assess, and the further a tool is from an inspectable source tree, the more of its answer you are taking on faith. That is not a claim about any country of origin. Grok’s agent was American and did the same thing.

Check your own machine

Ten minutes, and you will know more about your laptop than you did this morning.

1. Find out how much disk your agent tooling is holding. Agent tools keep their state in dotfolders in your home directory. Sort by size and look for anything that is large without a reason.

# macOS and Linux
du -sh ~/.[a-z]* 2>/dev/null | sort -h | tail -20

A conversation history is measured in megabytes. If a coding tool’s folder is in the hundreds of megabytes or into gigabytes, it is storing copies of something, and you want to know what.

2. Look for archive or snapshot files inside it.

find ~/.zcode ~/.cursor ~/.codeium ~/.continue ~/.config 2>/dev/null \
  -type f \( -name '*.enc' -o -name '*.tar.gz' -o -name '*.zip' -o -name '*.bundle' \) \
  -size +10M -exec ls -lh {} \;

Adjust the list of folders to the tools you actually run. Anything over ten megabytes that looks like a packaged copy of a project deserves an explanation from its vendor’s documentation.

3. Watch what it connects to while it runs. With the tool open and idle, not mid-task:

# macOS
lsof -i -P -n | grep -i ESTABLISHED

# Linux
ss -tnp

A coding agent that is not currently answering you should not be maintaining persistent connections to object storage. Connections to the model API are expected. Connections to a storage bucket are a question.

4. Find out what is in your own history before someone else does. Whatever leaves your machine, this matters independently:

# every secret-shaped string ever committed, including in deleted files
git log -p --all -S 'BEGIN PRIVATE KEY' --oneline
git log -p --all -S 'sk_live_' --oneline
git log -p --all -S 'AKIA' --oneline

# how much history exists at all
du -sh .git && git rev-list --objects --all | wc -l

For a real audit use a dedicated scanner such as gitleaks detect --no-git=false or trufflehog git file://., which check the full object graph rather than the current tree. If you find something, rotating the credential is the fix. Rewriting history is a separate and much more disruptive decision, and it does not un-share anything that already left.

What to actually change

Four things, in the order we would do them.

Separate the secrets from the repository, permanently. Not “remove the .env from git.” Establish that production credentials never exist in a directory that is under version control on a developer machine, in any branch, in any year. Development uses development values. Production values live in the deployment platform’s secret store and are injected at runtime. This makes the entire class of incident survivable rather than catastrophic, because what leaks is a set of throwaway values.

Give agents their own boundary. Run the tool in a container, a VM, or at minimum a separate OS user account whose home directory contains nothing but the one project it is working on. The principle is not that the tool is malicious. It is that you should be able to state, in one sentence, exactly what a piece of software is able to read. If the answer is “everything I have ever worked on, plus my SSH keys,” that is true of most people’s setup by default, and it does not have to be.

Decide per repository, not per tool. Our own split is that anything open source can go through whatever produces the best result, and client work goes through tools whose data path is documented and whose vendor we have an agreement with. This costs almost nothing to implement and it is the single control that would have limited the blast radius in both of these incidents.

Get the answer in writing before you need it. For any tool that touches client code, get the vendor to answer, on a page you can link to: what leaves the machine, where it lands, who the subprocessors are, how long it is kept, and how to turn it off. If they cannot answer, that is an answer. The OPC’s eleven points above are a perfectly good template, and they have the useful property of being the same questions your client will ask you.

The uncomfortable summary

The tool you installed to help you write code has, by design, read access to everything in the directory you pointed it at, and network access to its vendor. Those two properties are the product. They are not going away, and they are not a bug.

What changed in 2026 is that we now have two documented cases, ten weeks apart, of major vendors quietly connecting those two properties in a way no customer agreed to, and being found out by individuals who happened to look at their own disk usage. In neither case did a security product catch it. In neither case did the privacy policy describe it. In both cases the vendor’s response was fast, apologetic, and structurally identical.

The lesson is not “avoid Chinese tools” or “avoid American tools.” It is that the category is young, the incentives point one direction, and the only durable protection is the boring kind: keep secrets out of repositories, keep agents inside boundaries, keep client work on documented paths, and check your own machine occasionally, because as of this month that is twice where the finding came from.

---

If you run a business in Toronto and you are not sure what your development tooling is sending, or what you have promised your clients about it, get in touch. It is a short conversation and usually a cheap fix. We also write up the month’s security and patching stories in the same plain language.

Sources

Vendor and regulator primary sources, each retrieved and read on September 20, 2026:

• ZCode Releases and Updates changelog, Z.ai, for the release dates of 3.14.0 (September 19, 2026) and 3.12.3 (September 17, 2026), for the verbatim bug-fix line “Fixed an issue with abnormal uploads in the repository wiki,” for the count of eleven new features and sixteen bug fixes in 3.14.0, for the quoted line “The approval dialog now supports directly granting full access,” and for the fact that the published changelog reaches back only as far as 3.10.1 on August 28, 2026. The observation that the bug-fix line is the entire public record of the incident is ours.
• Z.ai privacy policy, carrying “Last Update: September 29, 2025,” for the quoted definition of User Content as “any text prompts, images, or other data you input,” for the quoted statement that “we generally provide the Services from Singapore,” and for the absence of any reference to workspace snapshots, repository packaging or codebase indexing anywhere in the document
• zai-org organization repositories, GitHub, for the finding that as of September 20, 2026 the organization publishes zcode-plugins (last updated September 17) and feedback (last updated August 17) and no repository containing the ZCode client source
• xai-org/grok-build, GitHub, for the Apache 2.0 licence, 47 commits on the main branch, 26.9k stars and Rust as the primary language
• Cursor Data Use and Privacy Overview, last updated September 3, 2026, for the description of codebase indexing computing embeddings from uploaded chunks with plaintext discarded, for the Privacy Mode zero-retention arrangements, and for the statement that with Privacy Mode disabled Cursor “may use and store codebase data, prompts, editor actions, code snippets, and other code data”
• Claude Code data usage documentation, Anthropic, for metrics excluding code, prompts and file paths, for secret redaction before error reports leave the machine, for the DISABLE_TELEMETRY and DISABLE_ERROR_REPORTING environment variables, and for the commercial-terms position on model training
• Guidance on assessing third-party service providers, Office of the Privacy Commissioner of Canada, draft published September 10, 2026 and open for comment until December 4, 2026, for the eleven recommended practices summarized above. The OPC’s own news release of September 10 carries the announcement. Note that the OPC web server did not respond to our requests on the morning of September 20; the guidance’s contents and consultation deadline are corroborated by Bennett Jones’ summary of the same date. The mapping of the eleven points against the ZCode timeline is ours.
• PIPEDA Fair Information Principle 1, Accountability, OPC, for the existing requirement that an organization remains responsible for personal information transferred to a third party for processing and must use contractual or other means to secure a comparable level of protection

Researcher write-ups. These are attributed to their authors and are not vendor-confirmed:

• ferstar, “Inside ZCode: Silently Uploading Your Entire Git History to the Cloud”, September 18, 2026, for the 700 MB ~/.zcode directory, the ~/.zcode/v2/checkpoints path, the 313 MB encrypted archive built from 345 MB of a 10 GB workspace, the failureCount of 564, the breakdown of a snapshot of 42,411 files, the quoted 86.6 percent .git share, the POST /api/v1/snapshot/upload-credential endpoint, the AES-256-CTR plus RSA-OAEP-SHA256 envelope scheme, the Aliyun OSS destination, the optimizeAgentExperienceEnabled and repoSnapshotIndexingEnabled configuration keys, and the account of what changed in 3.14.0
• Ruohang Feng (Vonng), “Zhipu, Why Is ZCode Packaging and Uploading My Repositories?”, September 18, 2026, for the independent reproduction on ZCode 3.12.3 on macOS, the four workspace snapshots and their plaintext and encrypted sizes, the 93.9 percent .git share and 8,323 of 9,619 files in the silo snapshot, the presence of git-filter-repo metadata and dangling objects, the 1,339 log entries recording the snapshot indexing setting as false between September 13 and 18, and the conclusion that collection is decided server side
• Hacker News discussion of the ferstar post, September 18, 2026, 329 points, for the translated text of Z.ai’s statement posted in-thread, for the report from a long-time ZCode user who found no checkpoints directory and no capture activity, and for the identification of a widely circulated English write-up as a machine paraphrase of the original

Reporting, used for facts we could not retrieve first-hand:

• Z.ai’s statement of September 18, 2026, as reported in Chinese technology press including PANews, for the attribution to the codebase indexing and Repo Wiki features, the claim that uploaded data is destroyed immediately after Wiki generation, the acknowledgement that the feature was enabled by default at launch, the open-sourcing commitment, and the extra weekly quota reset
• Taiyuan Chengming Technology’s letter to Beijing Zhipu Huazhang Technology, reported September 20, 2026, for the list of demands, the October 10 deadline for a written reply, the description of uploaded material including database passwords and cloud service credentials, the figures of 32,932 files and roughly 411 million plaintext characters, and the assertion that upload activity was still observed after 3.12.3 shipped
• Grok CLI uploaded the whole home directory to GCS, Hacker News, July 13, 2026, and Grok Build is open source, July 15, 2026, for the July timeline
• Simon Willison, xai-org/grok-build, now open source, July 15, 2026, for the Apache 2.0 release, the account of what the CLI had uploaded, xAI turning default retention off on July 12 and committing to delete previously retained coding data