ZCode uploads your git history; Z.ai holds the only key

Models
Hardware
Rigs
Use cases
Guides

Tooling
▾

Agent harnesses
Autonomous agents
Business AI
Marketing agents
Agent workspaces
Agent monitoring

Harness benchmark

Calculator
Tokens / sec

Claim your /u/name
Sign in

Models
Hardware
Rigs
Use cases
Guides
Calculator
Tokens / sec

Tooling
Agent harnesses
Autonomous agents
Business AI
Marketing agents
Agent workspaces
Agent monitoring
Harness benchmark

Theme

Claim your /u/name
Sign in

Guides

ZCode uploads your entire git history, and only Z.ai holds the key

Published
Sep 18, 2026

▲ 0
Join free to upvote

Contents

What gets packed

The toggles do not stop it

The privacy policy does not mention it

The context that makes it worse

The defense that works

What it means for local

On September 18, 2026, a developer going by ferstar published a reverse-engineering walkthrough of ZCode, the AI coding desktop app from Z.ai, the Beijing-headquartered company behind the GLM family of open-weight models - the same models running on local rigs all over the local-AI community, including GLM-5.3-Flash, tracked on this site. The finding reads worse than most privacy scandals: whenever the app is logged in, it silently packages the user’s entire workspace - complete .git history, LFS asset cache, reflogs, and global app configs - encrypts it, and uploads the archive to Aliyun OSS, Alibaba Cloud’s object storage. The researcher’s own capture: a 313MB encrypted archive built from a 345MB commercial workspace, 42,411 files, with 564 failed upload attempts logged while the researcher investigated.
If you run GLM locally, the company that publishes the weights is not the same thing as the runtime a developer might use on top of them - and the thread reaction showed the confusion is live: several commenters assumed ZCode was open source because GLM is. It is not. The weights are open; the harness is closed, and it is Z.ai’s harness for its own models, pitched as first-party integration no third-party editor can match.
The story spread in both languages within hours: ferstar’s post passed 276,000 views, and FeiZ’s Chinese-language alert thread (“disable ZCode for now… it’s still best to use open-source agents as much as possible”) drew another 63,800. The most quoted response came from Petri Kuittinen, whose own AI agent is open sourced with security documentation: “My advice has been and continues to be: do NOT trust closed source AI harnesses.”
The detail that turned a suspicious directory into a story: the encryption key. ZCode uses envelope encryption - the payload is encrypted with a symmetric key, and that key is wrapped with an RSA-OAEP public key. The public key is delivered by the server during upload-credential negotiation. The corresponding private key lives only in Z.ai’s cloud. ferstar attempted to unwrap the archive with every private key on the local system and failed. The 313MB ciphertext sitting on the user’s own disk cannot be decrypted by the user or by the ZCode client itself.
ferstar’s conclusion, from the post: “A key that only the server can use serves exactly one purpose: making sure the server can read your code whenever it wants.”
What gets packed
The packaging manifest is stored locally in plaintext, and it is specific. For a 42,411-file snapshot:

Content
Size
Share

.git/lfs/
196.1 MB
56.8%

.git/objects/
102.2 MB
29.6%

.git/logs/
0.6 MB
0.2%

Source code and docs
46.2 MB
13.4%

The .git directory alone is 86.6 percent of the payload.
Payload breakdown of one 42,411-file snapshot: the .git directory is 86.6 percent of the encrypted archive.
::: That matters because a git object store is not a snapshot of your working tree - it is the complete lineage of the repository since day one. Deleted-in-a-later-commit API keys are in there. Unpushed branch names that reveal unreleased product plans are in there. Internal hostnames and repo paths from .git/config are in there. A captured archive is years of engineering history, not the files you had open.
The upload pipeline, reconstructed from the client’s app.asar: the client requests credentials from zcode.z.ai, which returns OSS form signatures, an object key, a size cap, and a per-round RSA public key; the client packs the workspace to tar.gz, encrypts with AES-256-CTR, wraps the symmetric key, and POSTs the archive directly to Aliyun OSS, which callbacks to Z.ai’s backend to register the snapshot. The running client maintained persistent connections to zcode.z.ai and two Aliyun OSS nodes during the test.
:::figure
/images/articles/zcode-git-upload/upload-flow.svg
The reconstructed ZCode snapshot upload flow: credentials from the coordinator, local packing and encryption, direct form POST to Aliyun OSS, callback registration. Reconstructed from the client app.asar by ferstar.

The toggles do not stop it
The natural move is opening settings. ferstar cross-referenced the UI switches against the code:

“Optimize Experience” (optimizeAgentExperienceEnabled) only controls whether data is authorized for model training. Snapshot capture and upload continue.
“Repo Snapshot Indexing” (repoSnapshotIndexingEnabled) only controls whether the server indexes uploaded snapshots. Local packaging and upload continue.

The host assembly instantiates the capture sidecar unconditionally at startup, with no gating on user preferences - the only requirement is that the token provider can produce a valid JWT. Session logs showed 62 capture events from a single active session, triggered before every prompt and on task completion.
A second source corroborates the mechanism. OrcaPromptVault, a public collection of captured AI harness prompts, holds a 131KB system prompt and a 31-tool surface from ZCode. The checkpoint/rewind feature is wired into the system prompt - the template “Workspace rewind applied. rewindId, checkpointId, strategy, restoredFiles” appears five times. This is the user-facing tip of the snapshot pipeline, the feature the filesystem lock disables.
The agent’s complete tool surface contains zero snapshot, upload, or telemetry tools. The exfiltration pipeline is not an agent tool; it is a host-level sidecar instantiated outside the tool loop. That is why no permission setting stops it, and why the agent itself never sees it. Across 131KB of captured instructions there is no mention of Aliyun, OSS, uploads, or privacy.
The capture adds a detail ferstar did not mention: ZCode ships a ReadSessionContext tool that reads other persisted ZCode sessions on demand by session ID. Combined with the host-level snapshot sidecar, session content is both locally persisted and cloud-captured.
The leaked system prompt’s checkpoint template (appears five times) and the agent’s 31-tool surface, which contains no snapshot, upload, or telemetry tools.

The privacy policy does not mention it
ZCode’s privacy policy states the tool collects “text, files, and code submitted during conversations” - the standard inference-context disclosure every AI coding tool makes. Across the policy, FAQ, and changelog, ferstar found no mention of packaging and uploading entire workspaces and git histories. The closest line is a template statement about the optimization program being off by default.
The context that makes it worse
ZCode launched in July 2026, and its launch pitch ran directly on trust. Z.ai positioned the harness against Anthropic’s Claude Code weeks after the Claude Code hidden-telemetry controversy, with open weights positioned as the escape from the kill-switch problem. A Z.ai executive, asked on X whether ZCode would include “any sort of spyware,” answered that the company would not implement “anything beyond what’s listed” on the ZCode website.
Workspace snapshotting is not listed on the ZCode website.
Z.ai went public on the Hong Kong Stock Exchange in January 2026. The company’s official X account had not responded to ferstar’s post as of publication. The most visible reply came from an account affiliated with the ZCode team - “hey I am sorry to let you find it” - which reads as confirmation of the mechanism, not a rebuttal of it. ferstar’s tweet passed 276,000 views within 13 hours, and discussion threads on V2EX and HN-adjacent channels split mostly along one line: agents upload code fragments during tool calls all the time, with consent. This is a full repository plus its entire history, without consent, encrypted so only the vendor can read it.
The defense that works
Deleting the pending archive does not work: the client re-packaged a fresh 313MB archive within half an hour, retry counter incrementing. The fix that holds is filesystem-level. Make the checkpoints directory unwritable at the kernel level:
Linux:

Copy

rm -rf ~/.zcode/v2/checkpoints
mkdir -p ~/.zcode/v2/checkpoints
sudo chattr +i ~/.zcode/v2/checkpoints

macOS:

Copy

rm -rf ~/.zcode/v2/checkpoints
mkdir -p ~/.zcode/v2/checkpoints
chflags uchg ~/.zcode/v2/checkpoints

The trade: the checkpoint rollback UI stops working - a feature that required uploading your code in the first place. Chat, autocomplete, and tool calls work normally. Restore with chattr -i or chflags nouchg.
What it means for local
Running open weights locally is the pitch: your model, your hardware, no per-token bill, no vendor switch-off. The ZCode story sharpens the point past the model layer. The runtime around the model - the harness, the desktop app, the update pipeline - is part of the trust surface, and a locally-running model wrapped in a cloud-phoning harness is not local.
Two checks follow from this, and they apply to every harness in this space, not only ZCode: what does the runtime transmit when you are logged in, and who can decrypt what it stores. Tokenstead tracks agent harnesses and their telemetry behavior for exactly this reason; this piece will be updated if Z.ai responds with a fix, a disclosure change, or a statement.
Sources:

Inside ZCode: Silently Uploading Your Entire Git History to the Cloud - ferstar, September 18, 2026 (full forensics: asar reconstruction, encryption flow, manifest breakdown)

ferstar on X - the summary thread, 276K views

FeiZ on X - Chinese-language alert thread, 63.8K views

ZCode releases and changelog - Z.ai official

V2EX discussion thread - community response, Chinese
lookonchain coverage

Related guides

AI agent liability: contracts, insurance, and the gap
Sep 2026

China may curb open-weight AI exports: what it means
Jul 2026

GLM-5.3: the coding upgrade that found 1,097 critical bugs
Aug 2026

Tokenstead Weekly

One email every Monday: new open-weight models, community benchmarks, the
pricing moves that matter, and any new guide - before it scrolls off.

Weekly digest

Double opt-in. Unsubscribe with one click.

Discussion

Be the first to comment

Start a discussion
Got a take on this, a rig to show off, or a benchmark that says otherwise? Sign up and start the thread - your comment publishes instantly once you're in.

Sign up to comment
Tokenstead on X

Tokenstead Weekly

New open-weight models, real community benchmarks, and the
cloud-pricing moves behind them - what moved in local AI this
week, every Monday.

Double opt-in. Unsubscribe with one click.

Prefer an account? Join free
- save your rig, get personalized fit answers on every model page.

Weekly digest

TOKENSTEAD - AI IS BETTER AT HOME

© 2026 Tokenstead. All rights reserved.

Claim your /u/name
About
Agent harnesses
Autonomous agents
Business AI
Marketing agents
Agent workspaces
Agent monitoring
Harness benchmark
Contact
Terms
Privacy
X
YouTube

A reverse-engineering walkthrough of ZCode, an AI coding desktop application developed by Z.ai, revealed a significant mechanism for data exfiltration, suggesting that Z.ai retains control over user workspace information through its application harness. The investigation involved analyzing the application to determine what data is collected, how it is protected, and where it is ultimately stored. When a user logs into ZCode, the application silently packages the entire workspace, including the complete .git history, LFS asset cache, reflogs, and global application configurations, encrypts this collection, and uploads the resulting archive to Aliyun OSS, Alibaba Cloud's object storage. The researcher analyzed a snapshot of a 42,411-file workspace, finding that the .git directory accounted for 86.6 percent of the encrypted payload, emphasizing that the captured data represents years of engineering history rather than just the currently open files.

The data exfiltration pipeline was reconstructed by examining the client application's files, revealing a comprehensive flow: the client requests credentials from zcode.z.ai, which returns necessary keys and parameters, followed by local packing and encryption using AES-256-CTR. This symmetric key is then wrapped using an RSA-OAEP public key, with the corresponding private key residing exclusively on Z.ai’s servers, thereby ensuring that only the vendor can decrypt the archive. The endpoint was Aliyun OSS, where the archive is posted directly, triggering a callback to Z.ai’s backend for registration. This process demonstrates that the encryption key is managed entirely by the server, meaning the user cannot decrypt the data, as the researcher attempted to unwrap the archive with local private keys and failed. This finding suggests that the server's possession of the private key is solely to maintain the ability to read the code whenever desired.

The mechanism is not mitigated by the user-facing settings within the application. Switches such as "Optimize Experience" or "Repo Snapshot Indexing" do not gate the capture and upload processes; these controls are separate from the core data exfiltration pipeline. Furthermore, the exfiltration is executed by a host-level sidecar instantiated outside the agent's tool loop, meaning no permission setting within the agent grants or denies this access. An additional discovery involved the presence of a ReadSessionContext tool within ZCode that allows on-demand reading of other persisted ZCode sessions by session ID, combining with the host-level snapshot mechanism to ensure persistent cloud capture of session content.

Despite the opaque data handling, ZCode’s privacy policy is found to be limited, stating that the tool collects only the text, files, and code submitted during conversations, omitting explicit mention of the packaging and uploading of entire repositories or git histories. The context surrounding the launch, positioned against competitors, did not alleviate concerns regarding transparency; the existence of this comprehensive, non-consensual upload of repository history—encrypted and held by the vendor—presents a critical vulnerability in the trust surface of AI coding harnesses.

To counter this exfiltration, a defense based on filesystem permissions proved effective. Direct attempts to delete the pending archive failed because the client immediately re-packaged a fresh archive, incrementing retry counters. The successful defense involved enforcing filesystem-level locks on the checkpoint directory by making the directory unwritable at the kernel level using commands like chattr +i on Linux or chflags uchg on macOS. This action successfully prevented the system from executing the planned upload, although it disabled certain features, such as the checkpoint rollback interface, which were dependent on the initial code upload.

Ultimately, the findings imply that running local open-weight models is not sufficient protection if the surrounding runtime harness is built upon an untrustworthy cloud-phoning mechanism. The case of ZCode highlights the necessity for scrutiny across the entire stack, focusing on what data is transmitted, who can decrypt it, and the architecture of agent harnesses, emphasizing the need for scrutiny over the runtime environment itself.