After reading Ferstar's investigation, I checked the ZCode installation on my own Linux machine. I wanted to separate what the article claimed from what the installed client actually contained.

The installed build was ZCode 3.8.1. Its Electron archive, /opt/ZCode/resources/app.asar, contains a repository-snapshot pipeline in out/host/index.js.

What the code confirms

The scanRepoSnapshot code runs git ls-files --cached --others --exclude-standard and then walks the repository's .git directory. That means the snapshot logic is designed to collect Git metadata, not only the files needed for the current prompt. It includes objects, refs, logs, and LFS data, although it does skip some secret-looking paths, binaries, and large files.

The files are written into a gzip-compressed tar archive. The archive is encrypted locally with AES-256-CTR. The AES key is temporary and is wrapped with RSA-OAEP-SHA256 using a public key received from the server. I found no private-key handling in the client, so the client can create the ciphertext but cannot decrypt it itself.

The upload path is also explicit. ZCode requests snapshot credentials from /api/v1/snapshot/upload-credential, receives Alibaba OSS form fields such as x-oss-signature and x-oss-security-token, and sends repo-snapshot.tar.gz.enc in a direct multipart POST to the OSS host. I did not find an AWS S3-specific implementation.

The snapshot sidecar is created during host startup even though my settings contained both optimizeAgentExperienceEnabled: false and repoSnapshotIndexingEnabled: false. The capture hooks are connected to local prompt handling and task completion. A valid token is required, but there is no per-upload confirmation in this path.

What my machine can—and cannot—prove

The local logs show ZCode running on August 19 from 15:55:32 until 16:40:07. The last recorded interactive task activity was at 16:24:28; after that, the process continued making background requests until it exited. There was another shorter run on August 14.

I found no remaining .enc, tar, manifest, or checkpoint artifacts, and no retained log entry that proves a particular snapshot was successfully accepted by OSS. So I cannot honestly claim that a repository definitely left this machine based only on the surviving evidence.

What I can say is narrower and more useful: the installed client contains a silent, server-keyed repository packaging and upload mechanism, and it could run from prompt/task hooks without an explicit upload action. Proving a historical upload would require packet captures, router records, or provider-side logs. Static code establishes capability and reachability; it does not reconstruct deleted network history.

That distinction matters. The article motivated the investigation, but the strongest conclusion came from checking the installed binary and then checking the local timestamps, databases, settings, and artifacts myself.

2026

What I verified about ZCode's silent workspace snapshots