Service eligibility and regional restrictions
PuppyIP serves only compliant overseas businesses and their authorized personnel. Proxy services are not available in mainland China. The service may only be used for lawful business activities outside mainland China. Use of this service within mainland China is prohibited.
Hosting a proxy IP or server overseas does not change these restrictions. The service must not be provided to end users in mainland China through relaying, forwarding, sharing or resale. Before use, read the Terms of Service.
Key Takeaways
- The researcher reconstructed ZCode 3.12.3’s workspace packaging, server-supplied encryption material, direct object-storage upload and callback registration flow. Local manifests showed that snapshots could include .git objects, LFS, reflogs, source and configuration.
- The widely discussed 313 MB commercial-repository snapshot remained pending and never left the researcher’s network. A separate small public repository received an accepted result from the server. These must not be combined into “a 313 MB private repository was uploaded.”
- The vendor’s reported September 18 statement acknowledged that the capability was enabled by default for some early users and said it had been fixed. The researcher reported the upload path removed in 3.14.0, and the current public repository also lacked the old pipeline.
- The current open-source repository contains only a small number of flattened commits and cannot establish all past-version behavior. The full affected-version range, account count, historical server inventory, decryption access and per-user deletion proof remain UNKNOWN.
- First record the installed version, checkpoint/state data, file hashes, times and egress logs, then update or disable the old version. Do not delete local directories first, as that may destroy evidence distinguishing pending, failure and accepted.
- Credential rotation depends on Git history and snapshot scope. If historical objects, configuration or LFS contain active secrets, revoke and reissue them according to exposure risk. Do not ignore past commits merely because the current workspace has no plaintext secrets. PRODUCT_FIT=NONE: changing IPs cannot retrieve uploaded data or prove deletion.
Start with evidence boundaries: an upload pipeline does not prove every private repository was uploaded
On September 18, 2026, the researcher published local files, decompiled logic and the request chain from ZCode 3.12.3. The client archived and encrypted the workspace, obtained upload credentials and a public key from zcode.z.ai, then uploaded ciphertext directly to object storage. The sample’s plaintext manifest showed that the scope could include complete .git history, LFS, reflogs, source and global ZCode configuration. Disabling two interface settings still did not stop the old version from creating snapshots and attempting uploads.
Whether a particular repository actually left the machine must be assessed individually. The 313 MB commercial-repository sample recorded 564 failures and remained pending; the researcher explicitly said it was not successfully uploaded. A separate small public repository showed accepted. User reports such as GitHub #715 establish independent concerns or local state, but cannot replace a vendor-side object inventory for each account.
Version matrix: what 3.12.3, 3.14.0 and the current open-source tree each establish
3.12.3 is the affected sample in which the researcher directly reconstructed snapshot creation and the upload pipeline. The researcher later examined 3.14.0 and reported that the pipeline had been removed and the upload-credential path returned 404. This supports the conclusion that the new version no longer uses the same path, but does not automatically establish the precise scope of every build before and after 3.12.3.
Z.ai’s current public ZCode repository can be used to review present code. The researcher did not find the old upload endpoint, object-storage upload, old encryption or Repo Wiki pipeline in it. However, its history is flattened and lacks the complete evolution needed to map old versions to the fixed version commit by commit. The correct conclusion is “the old path was not found in the current open-source tree,” not “the historical behavior never existed.”
Step one: preserve local evidence before deciding to update or clean up
Without restarting the old client or increasing network traffic, record the installed ZCode version, last run time, login state and affected workspaces, plus the paths, sizes, modification times and hashes of checkpoint, state, manifest and log files under ~/.zcode. Screenshots are supplementary; structured files and hashes are better for later verification.
Do not begin by deleting pending directories, reinstalling the system or clearing logs. Copy necessary evidence to a controlled location with restricted access first, then have the security or legal owner determine retention. For an enterprise-managed machine, also preserve proxy, DNS, firewall, EDR and object-storage-domain access records. If logs are unavailable, record UNKNOWN. “Not found” must not be described as “not uploaded.”
Step two: distinguish pending, failure and accepted rather than checking only file existence
The state fields, failureCount and accepted results in the research material provide different strengths of evidence. Pending or numerous failures more closely support “packaged locally and repeatedly attempted,” while accepted more closely supports server-confirmed receipt. Even if a local file later disappears, that does not establish deletion in the cloud: client cleanup, upgrades and server lifecycles may occur independently.
Create a separate row for each workspace with version, snapshot ID, state, failure count, package size, manifest scope, earliest/latest times, matching egress records and evidence confidence. Do not substitute the researcher’s accepted result for a small public repository for a conclusion about your own account, or treat descriptions in user issues as the vendor’s ledger.
Step three: assess credentials and intellectual-property risk across Git history
Complete .git objects may retain API keys, private keys, configuration, internal domains, unpublished branches and LFS assets deleted from the current branch. Use existing approved secret-scanning and history-review procedures on repositories suspected of being packaged. Prioritize credentials that remain valid, carry high privileges, work from the public internet or permit lateral access. Do not copy secret values into ordinary tickets or chats.
If active secrets are found, revoke or rotate them first, update deployments, CI and dependent systems, and inspect unusual usage records. Local pending state with egress evidence supporting unsuccessful upload can be graded separately from accepted, but the old version’s unclear consent boundary and continued retries still need handling. For customer code, trade secrets or regulated data, use the organization’s incident-response, legal and vendor-management processes to assess notification obligations.
Step four: verify the fix without treating a vendor statement or current open-source version as deletion proof
After updating to an organization-approved fixed version or temporarily disabling the client, validate with a test repository containing no sensitive data: confirm that old-style snapshots are no longer generated, the old upload-credential path is no longer requested, and the corresponding direct object-storage upload chain is no longer used. Record the version and observation window. Do not give a real private repository back to an old version or deliberately trigger more uploads for reproduction.
The vendor’s reported statement says the early default capability was fixed and data is not retained. The researcher also relayed a summary of bucket deletion and third-party checks. However, a complete audit report, historical object inventory, decryption-access records and per-user deletion proof were still not directly public during this review. Record these as vendor statements and unresolved items, not as an independent audit proving that all historical data was never retained.
Stop conditions, escalation and later checks
If evidence directories are still changing, the old client is still running, accepted appears, egress logs match upload targets, high-value secrets exist in history, or the processed repository scope cannot be established, stop ordinary use and escalate to the internal incident-response owner. Preserve the timeline, hashes and access controls on original files. Request account-level snapshot IDs, receipt times, decryption access, retention/deletion records and audit reports from the vendor.
Even if the current version passes validation, review again before the vendor reintroduces Repo Wiki, cloud indexing, checkpoint synchronization or hot-update capabilities. Fixed network egress can help an organization observe allowed traffic, but cannot retrieve historical objects, replace evidence preservation, provide proof of vendor deletion or guarantee that the client will remain unchanged.
Sources
Frequently Asked Questions
Was the researcher’s 313 MB commercial repository uploaded?
No. The researcher explicitly recorded 564 failures and a pending state; that snapshot did not leave the network. The successful accepted result came from a separate small public repository. Do not conflate them.
Which ZCode versions were directly checked?
The investigation directly reconstructed the 3.12.3 upload pipeline and reported that 3.14.0 had removed it. The current open-source tree also lacked the old pipeline. The complete affected-version range remains unknown.
Does upgrading complete incident handling?
No. An update can stop continued use of the known old path, but cannot prove the status of historical accepted objects, decryption access or deletion. Local state, egress evidence, secrets in Git history and vendor account-level records still need checking.
Why not delete ~/.zcode before investigating?
The directory may contain versions, snapshot IDs, pending/failure/accepted states, timestamps and manifests. Deleting it first destroys evidence needed to establish actual scope. Preserve it under controlled access before cleanup through organizational procedures.
When should keys be rotated?
If the suspected snapshot scope includes active secrets, particularly high-privilege credentials, credentials usable from the public internet or those allowing lateral access, revoke and reissue them under the incident-response process. Looking only at the current workspace misses historical Git objects.
Can changing a proxy or IP address resolve historical upload risk?
No. Network egress cannot retrieve accepted objects, prove server-side deletion or fix an old client. At most, it helps observe and restrict subsequently allowed traffic.