The changelog line does not name the files that left

ZCode 3.14.0, in 19 September 2026 release notes, says it fixed abnormal uploads in the repository wiki. The same note also adds dynamic workflows that orchestrate multiple sub-agents from one script, Office and Coding modes, and an approval dialog that can grant full access. For a developer the binding contract is whether a wiki upload carried .git history, an Large File Storage (LFS) cache, or filtered source text, and the changelog does not say.[1]

That gap is what makes the desktop coding app's agent layer substitutable: the release note offers a closed bug, but it does not measure which bytes left the machine. A team that wants to move the agent to another tool cannot price the switching cost until that egress is visible. Another reading is also open: the wiki upload may already have been a narrow indexing path, and the changelog may only have closed a fault on that path.[1]

An independent diff does not measure destroyed-immediately

ferstar writes that while a user is signed in, ZCode encrypts a workspace snapshot and uploads it to Aliyun Object Storage Service (OSS); in one example a 345,549,173-byte workspace packed to 313,070,842 encrypted bytes. The 19 September update reports Z.ai's 18 September statement: the issue came from codebase indexing, generating Wiki pages in the cloud may trigger a repository-data upload, and uploaded data is destroyed immediately. That uploads occurred is no longer contested by the company; what remains is scope, key handling, and how anyone outside is supposed to verify destroyed-immediately.[2]

An updated comparison table claims the remediated build dropped full-workspace snapshots and stripped the upload pipeline; that table is the author's own diff rather than a third-party audit report. Set beside the 3.14.0 changelog, the function is clear: the vendor closes a wiki-upload fault, and the independent post says its own measurement shows the full snapshot fell away. Where the two do not meet is verification of destruction in the cloud. The observable next step is the promised open-source tree plus a third-party review that names the file list of an upload; until that arrives, 3.14.0 remains a closed-bug line.[1], [2]