Coding agent privacy checklist after the ZCode backlash

SilenceStar found six local workspace snapshot manifests in ZCode 3.10.1.6272, including one manifest totalling 965 MB. The inspection found that 961 MB came from the Git directory. That makes local artefacts, network requests and account state essential checks before a team approves a coding agent.

The ZCode case is not proof that every coding agent uploads repositories. It is evidence that a visible setting, a product label such as “indexing”, and an encrypted local archive do not answer the same question. Teams need to establish what the installed client reads, packages, stores and can send.

What should a coding-agent privacy checklist test?

A useful checklist tests two separate risks. First, an agent host may collect workspace material, prompts or metadata outside the obvious chat flow. Second, the agent may write code that works in tests but fails security review.

These risks can overlap. A repository snapshot can contain source code, commit history and past secrets. Agent-written code can also add exposed credentials, weak access controls or unsafe dependencies to that repository.

OWASP’s Artificial Intelligence Security Verification Standard describes testable controls for AI systems across data handling, deployment, access control, agent security and monitoring. Its Level 2 target is intended for production systems handling sensitive data or making consequential decisions. Treat that as a useful baseline for a coding agent with access to company code.

Which ZCode versions and conditions were exposed?

The public evidence covers specific builds and conditions, not every ZCode release or platform. The matrix below separates direct local observations from Z.ai’s reported public statement and from claims that remain unverified. That distinction matters because a snapshot on disk is not, by itself, proof of a completed upload or server retention.

The table does not establish exposure on Windows, Linux, web-only deployments or every macOS build. It does not establish that every logged-in ZCode user created a snapshot. It also does not establish that every requested credential led to an object upload.

What did Z.ai publicly confirm?

Ferstar reported that Z.ai issued a public statement on 18 September 2026 at 17:44. According to that report, Z.ai linked the issue to codebase indexing, local indexes, session checkpoint restore and Repo Wiki. The company said cloud Wiki generation could trigger an upload of repository data.

The same reported statement said the feature was enabled by default during an early launch period. Z.ai said some users were affected and that the issue had been fixed. It also said uploaded data was destroyed immediately after Wiki generation and was not stored.

Those statements are important, but they do not replace technical verification. A claim that a feature is fixed should be tested on the precise client version a team plans to run. A claim of immediate deletion requires server-side evidence, not only local client inspection.

What did the inspected ZCode client do?

SilenceStar inspected ZCode 3.10.1.6272 and local checkpoint records dated 16 August 2026. The report found six workspace manifests with timestamps from 20:08 to 23:41. One manifest, named harness, listed 965 MB of material.

The report says Git data accounted for 961 MB of that harness manifest. It identified a 915 MB Git pack file. This matters because Git history can contain deleted files, old configuration and credentials that are absent from the current working tree.

The inspected client separately collected workspace files and Git metadata. Workspace collection used Git’s standard file listing and applied ignore rules. The Git-metadata collector recursively scanned the .git directory.

Paths containing .git were included before later sensitive-name, size and null-byte checks. The report says the later checks therefore did not apply to Git pack files. A current .env exclusion is not enough if an earlier secret remains inside commit history.

The report says the snapshot package included meta/prompt.json. Its content field stored the prompt from that turn under the same snapshot identifier as repository state. That makes secret handling in prompts a data-collection problem, not merely a chat-policy problem.

Which local records indicate an upload attempt?

Local records can reveal capture and client state. They cannot prove cloud retention. Teams should describe those limits precisely when investigating an agent.

SilenceStar found three small packages with a lastAcceptedManifestHash and cleared pending directories. The report concludes that those client records support completed-upload status. Two related repositories were public, while another accepted record was an empty package.

Three larger encrypted packages remained pending locally. The pending group included a private repository snapshot. Each had an attemptCount value of one, but the report does not infer that a timeout caused each pending state.

The inspected implementation used a 60-second object-upload timeout. That detail explains one possible failure path. It does not establish whether any particular upload completed after the local inspection ended.

How should teams test host behaviour before approval?

Start with the installed host application, not the model’s marketing description. The host controls files, authentication, network access and local persistence. A model can only be as constrained as the surrounding application allows.

1. Document the application’s data directory, cache directory, checkpoint directory and session directory.
2. Create a harmless test repository with a known file list and no production secrets.
3. Send one prompt and compare directory contents before and after the action.
4. Record new manifests, archives, encrypted packages, retry files and upload-state files.
5. Inspect outbound requests for credential endpoints, object-storage hosts and API hosts.
6. Test logged-out and logged-in states separately.
7. Test local workspaces and remote workspaces separately when the product supports both.
8. Turn off each relevant setting, repeat the test and compare the host’s behaviour.
9. Keep a dated record of the exact application build, operating system and account state.

In the inspected ZCode 3.10.1 path, a local prompt scheduled a snapshot sidecar before the chat send. The same report says a remote workspace with workspaceIdentity skipped that path. That is why one successful test cannot stand in for every workspace mode.

The inspected host did not read the renderer fields needed to stop snapshot scheduling. The report found the displayed indexing setting off in setting.json. It also found that the relevant host scheduling condition did not use those fields.

Do not treat a disabled user-interface switch as evidence until a repeatable test shows that collection stops. This is a general procurement rule, not a claim that every agent’s settings are ineffective. The useful evidence is a before-and-after record of files and network requests.

Which controls can reduce exposure now?

Network controls are the clearest tested safeguard in the inspected ZCode flow. SilenceStar reports that failed retrieval of upload credentials stopped later scanning and encryption. In that build, the credential request was therefore a useful control point.

Use an allowlist that permits only approved agent services and blocks unapproved credential and object-storage destinations. Record the hostnames and paths used during a controlled test. Re-run the test after each client update.

Sign out where a coding agent does not need an account. The inspected ZCode path returned when no ZCode login token was available. That is evidence for this build, not a guarantee for later releases or other products.

Do not rely on filesystem locking of checkpoint directories as a verified ZCode mitigation. The available evidence does not include vendor documentation or a reproducible test showing that locking stops rollback while chat, autocomplete and tool calls continue. Teams that consider such a control should test it in an isolated environment and document any broken functions.

Local cleanup is a separate control. SilenceStar says deleting local checkpoint files cannot withdraw material already received by a server. Close the application before removing local data, and preserve records if an incident investigation requires them.

How should teams keep secrets out of prompts and snapshots?

Assume that a prompt can be stored with project context unless the installed product proves otherwise. Do not paste long-lived API keys, private keys or production credentials into agent chat. A redaction policy is helpful, but it should not replace technical limits on collection and retention.

• Keep deploy keys, signing keys and cloud tokens outside the working tree.
• Remove test credentials from Git history before sharing a repository with an agent.
• Use short-lived credentials where the surrounding system supports them.
• Review shell history, environment files and generated configuration before an agent reads a project.
• Use separate test repositories for evaluating a new agent.
• Check whether replay, checkpoint or restore features preserve prompts and diffs.

OWASP AISVS includes requirements covering access control, monitoring, agentic security and AI-assisted secure coding. It describes its requirements as verifiable, testable and implementable. That is the right standard for a coding-agent rollout: require evidence rather than accepting a product setting at face value.

Why must code security sit beside privacy controls?

Privacy controls do not make agent-written code safe. The SUSVIBES study evaluated 12 coding-agent settings on 186 feature-request tasks. The benchmark used real-world open-source projects where human programmers had committed vulnerable implementations.

SUSVIBES reports that SWE-Agent with Claude 4 Sonnet achieved 57% functional correctness and 11.8% security. The paper says all evaluated agents performed poorly on software security. A feature that passes tests can still introduce an authentication, data-handling or dependency flaw.

Tenzai reported 69 vulnerabilities across 15 applications built with five popular coding agents. Its report says every tested agent shipped vulnerable code. This is vendor research rather than a universal measurement of all agents, but it supports mandatory human review.

Require code review for authentication, authorization, input handling, dependencies and secret exposure. Use security scanning where it fits the development process. OpenAI’s Codex Security documentation, for example, describes local scans, CI checks and repository-connected cloud scans for finding and validating likely issues.

What is the approval checklist for a coding agent?

What could not be verified?

Public evidence does not establish that every ZCode build created snapshots, requested credentials or uploaded repository data. The direct local inspection covered ZCode 3.10.1.6272 on macOS, specific checkpoint records and a specific set of workspaces. It did not test other operating systems, all account types or all versions.

Public evidence does not establish the server retention period for snapshots uploaded before the fix. Ferstar reports that Z.ai said uploaded data was destroyed immediately after Wiki generation. Independent local inspection cannot confirm historical server deletion, processing or access without server-side records.

Public evidence also does not establish whether historical uploads were used beyond the functions Z.ai described. SilenceStar explicitly says its inspection did not verify server retention or training use. The report also says it did not inspect other versions or accounts.

ZCode’s public repository helps teams inspect the current desktop, web and CLI code. But Ferstar says the public release has two commits and flattened earlier history. That limits outside reconstruction of when older upload code was introduced or removed.