ZCode’s workspace uploads: what was observed and what changed

ZCode’s September incident concerns a reported background workspace-upload path. Later remediation evidence is version-specific; it does not establish present exposure or a completed independent security audit. Before giving a coding tool sensitive code, check the client’s data path as well as the model’s terms.

This October 15, 2026 review reads the complete researcher report and updates, official releases and selected public source. We did not run ZCode, reproduce uploads or inspect anyone’s private data.

What Ferstar reported

Ferstar attributes these findings to 3.12.3: packaging included .git history objects, large-file cache (LFS) and local reference logs (reflogs); upload credentials came from ZCode, with encrypted payloads destined for Alibaba Cloud object storage (Aliyun OSS). His 313 MB private-project archive remained pending after 564 failures. A separate 538-file public project, around 15 KB compressed and encrypted, was reportedly accepted. These outcomes must stay separate.

He reports that training and indexing switches did not stop that old upload path. A server-supplied public key is not evidence of user-exclusive decryption. We did not test that binary. Git-history inclusion can expose material absent from current files; it does not establish that actual secrets were stolen.

Dated versions and changes

Sources: official changelog, current inspected source, 3.14.3 commit. Ferstar names 328c1a0; current history shows 29628c9. That source-identity discrepancy remains unresolved.

Our bounded source inspection found checkpoint orchestration using a local Git implementation and local JSON metadata. That supports a narrow checkpoint finding, not “the app sends nothing.” Matching version labels would still require build evidence to establish binary equivalence.

Deleting a bucket cannot prove that earlier data was never accessed, copied or decrypted. Historical access, retention and key custody remain unresolved here. Remediation evidence deserves weight without becoming a universal safety claim.

Four layers to evaluate separately

Model: generates answers from supplied context. Capability and token price do not tell you which files a desktop application collects. None of these client, infrastructure or sharing incidents establishes a defect in the underlying model weights or proves the model otherwise safe.

Client, harness and tools: select files, run commands, manage history and connect services. A command-approval prompt may govern one tool action while other application traffic follows separate rules. ZCode’s current source notice documents that distinction and says the shared execution adapter has no default operating-system sandbox.

Provider infrastructure: receives requests, stores data and enforces server access. DeepSeek’s 2025 case covers the historical unauthenticated-database findings and unknown outside access. Closing a path does not reconstruct its earlier use.

Public sharing: publishes a conversation or snapshot to another audience. Claude’s shared-chat case concerns searchable public snapshots; it does not establish unauthorized access to unshared chats. Its undated screenshot establishes neither current indexing nor exposure scale. These incidents do not form a current provider ranking.

Which privacy terms apply?

The Chinese ZCode policy, §1, expressly covers accounts registered with mainland-China phone numbers. Its China-storage language is not a promise for every user. The English product policy names Singapore’s JINGSHENG HENGXING TECHNOLOGY PTE.LTD, generally describes Singapore processing and allows overseas transfers. Both display June 15, 2026; that displayed date does not prove historical text was unchanged.

The English policy documents opt-in training optimization, off by default, alongside service data collection and variable retention. “Training disabled” does not mean “nothing uploaded.” The English terms, §III(5), include supplied code, runtime logs, terminal outputs and tool results. Product, account, region and connected providers matter; an API policy cannot simply be substituted for desktop terms. These documents are provider commitments, not independent verification of historical handling or consent.

Six questions before granting repository access

Record documented, independently observed, or unknown beside each answer, with a version and date. Documentation describes intended behavior; observation covers only what was actually checked.

1. Files and history: Which files, ignored paths, Git objects, attachments and tool outputs leave? Ask about background collection as well as selected prompt context.
2. Destinations: Which model endpoint, gateway, storage service, plugin or remote tool receives each category? The source notice documents multiple paths; a provider label alone is insufficient.
3. Permissions: Which actions require confirmation, and what enforces the limit? Distinguish application rules from operating-system isolation and network controls.
4. Credentials: Where are keys stored, forwarded and synchronized? ZCode’s notice describes gateway forwarding and remote-environment credential flows. Source documentation does not establish every shipped configuration.
5. Retention: What survives cancellation, deletion and account closure, including logs, backups and recipients’ copies? Request product-specific periods and exceptions; historical snapshot handling remains unknown here.
6. Sharing: Is access public, organization-restricted or authenticated per recipient? OpenCode’s existing permissions and privacy guide distinguishes provider traffic from public session sharing. Review the entire visible conversation before publication.

Use the ZCode guide for the scoped product update and the harness comparison for workflow choices. Neither substitutes for resolving your repository’s data boundary.