A Chinese developer who publishes under the name ferstar was cleaning up his hard drive on September 18 to free up some space. He came across a file he hadn't created: 313 megabytes, encrypted, in a folder related to ZCode, a coding agent that lives on his desktop the way Claude Code lives on mine. He deleted it. He came back half an hour later, on its own, restored identically.

What was inside was his work. All his work. And he spent the following days taking the software apart to understand who was bundling it, when, and where it was going.

ZCode is Zhipu's desktop tool, the company behind GLM, which I was talking to you about just yesterday regarding the new FlashX version two and a half times more expensive. So they sell an agent that writes code in your projects. And apparently, it has a pretty broad view of what belongs to you.

What's inside the 313 megabytes

The researcher analyzed the archive, and the breakdown says it all. In a 345-megabyte project, only 46 megabytes are code and work documents. The rest, more than 86 percent, is the hidden .git folder: 196 megabytes of large files, and 102 megabytes of objects and history.

A word about this folder, because it's the heart of the problem. When you track your code with Git, this directory contains not only your current files, but also all the previous versions, the branches you abandoned without ever sending them, the history of every fix, and often traces of things someone committed and then removed. A Git repository is your house plus the boxes in the attic that you've never opened. And under the roof, there are sometimes the keys.

On a second machine, the same tool created a manifest of 7,946 files totaling 758 megabytes, with the .git folder accounting for 98.91 percent of the total. The software's filters do exclude node_modules, .env files, private keys and files whose names contain "token" or "secret". They never exclude .git.

The truck leaves at nightfall. Nobody asked it for anything, and it comes back tomorrow

Where it goes, and how it's packaged

Off to a storage space at Alibaba, the Chinese cloud giant. The archive is encrypted in two stages, with a symmetric key for the content and a public key sent by the server to wrap that key. Practical translation: the key that opens the package exists only on the server side. You have an unreadable file on your disk, and no way of knowing what's inside it or decrypting it.

The sending mechanism is even more troubling than the content. A small program starts when you log in and stays there permanently. It takes a snapshot of your workspace just before every request you send to the agent, and once again when the work is finished. In a single coding session, the researcher counted 62 triggers. His error log records 564 sending attempts that failed and tried again.

And then there's the killer question: the switches in the interface. There are three of them. The one that controls the use of your data for training. The one that controls the indexing of your repository on the server side. The one for the agent's memory. The researcher turned all three off, and the archive kept arriving. Because these settings decide what the server does with what it receives, not what your computer sends it.

A pretty panel, and a bundle of cut cables that lead nowhere. You can flip whatever you want, it doesn't cut anything

Zhipu's response

They deserve credit for one thing: they responded quickly. The publisher apologized, explained that snapshots serve two purposes, restoring your workspace after an error and automatically generating documentation for your project, and stated that the data on the server side is destroyed once the page has been generated. They committed to publishing the client code and having it audited by a third party.

The problem is what their own privacy policy says, which has not been rewritten since. Processing mainly goes through servers in Singapore, the data concerned includes the text, the configuration and the commands entered in the terminal, and it is kept for as long as the account exists. Nowhere does it say that the repository's complete Git history is extracted. So you cannot say that it is hidden, but you can say that it was not stated.

A second developer reproduced the thing on version 3.12.3, and a Windows user saw 32 snapshot workspaces one after another, up to 107 megabytes for the largest package. This is not an isolated case or a weird machine. And this is not the first time this year: in July, a coding tool from xAI, Grok Build, had already been called out for similar uploads.

What you do if you use a coding agent

First, if you have ZCode installed, you can make the snapshots folder impossible to write to at the system level, which is the only truly effective workaround:

# Linux
sudo chattr +i ~/.zcode/v2/checkpoints

# macOS
chflags uchg ~/.zcode/v2/checkpoints

# Windows, en PowerShell, dossier en refus d'écriture
icacls "$env:USERPROFILE\.zcode\v2\checkpoints" /deny "%USERNAME%:(W)"

And do not count on deleting the file that is already there, it recreates itself in half an hour. Also rotate any credentials that may have been lying around in an old commit, and avoid running this kind of tool on your main repository with your personal account.

The padlock is solid. The problem is, you are not the one holding the key

Next, and this is the real lesson, it is not just ZCode. A coding agent is a program that reads your files, modifies them and executes commands on your machine. To do its job, it necessarily has to see a lot. The question is not whether it sees, but what gets out of it, and whether it is written somewhere in plain language. Anthropic learned the same lesson three days ago with Claude Code, with a permissions control that had two blind spots.

My own rule has been simple for a long time, and it does not depend on any setting in any interface: anything that must not get out is not found in a folder an agent works on. Secrets in a separate configuration file, outside the repository. Client repositories on one machine, mine on another. This is not paranoia, it is the only defense left when the “stop sending” button does nothing.

There is one question nobody has asked Zhipu, and it bothers me more than the rest. They promised to open up the client code and have it audited. Fine. But how long did those 313 megabytes sleep at Alibaba, and how many other archives of the same kind are still sleeping over there, belonging to people who never noticed anything?