A coding agent needs access to your repository to be useful. But “access” can mean several things: reading the files needed for a task, examining earlier commits, or sending a copy elsewhere.

This week’s ZCode incident makes that difference hard to overlook. It’s a good reason to ask a question that rarely appears in coding-tool comparisons: what leaves the machine when the tool gets to work?

When you give a coding agent access to a project, you expect it to read the code it needs. Would you also expect it to package the workspace, including Git history, for upload to a cloud service?

That is what a developer investigating Z.ai’s ZCode found. On 18 September, they noticed an encrypted archive in ZCode’s local data directory. Its file list contained source files and .git data, which can include earlier versions of files and local work that is not visible in the current checkout. The archive was prepared for upload as part of ZCode’s repository snapshot workflow.

The distinction between attempted and completed upload matters here. The developer’s large archive of a private project remained pending after repeated failed attempts; the investigation does not show that archive reaching the cloud. A much smaller snapshot of a public repository did show a server-received status. That is enough to establish why the workflow needs scrutiny without claiming that the private project was successfully transferred.

The developer also found that settings concerning data use and indexing did not stop the snapshot capture and upload attempt. This is an easy distinction to miss: a control over what a service does with data after receiving it is different from a control over whether the data leaves your machine at all. Encryption does not settle the question either. In the documented workflow, the service supplied the public key used to protect the upload, leaving the corresponding private key on the service side.

Z.ai apologized and removed the snapshot-upload workflow in ZCode version 3.14.0, and published the tool’s source code. Those are material changes. They do not tell us how common similar behavior is across other coding tools, and the published current code alone cannot reconstruct everything an earlier build did.

What changes for an engineer? Treat repository access as a data-scope decision. Before putting a coding tool on a sensitive project, check what it reads, whether it collects the whole workspace or Git history, what it sends to a service, and which setting actually stops that transfer. For a team, those answers belong in the tool evaluation alongside coding quality and cost.

A coding agent can be excellent at its assigned task and still have a data path you would not have approved. Know that path before granting the access.

Linear says its test suites have nearly quadrupled since January and agents now write most of its tests. Its engineers changed runners and toolchains, removed repeated setup, and shortened small jobs that delayed the rest of the pipeline. Pull-request CI wait time fell from more than six minutes to just over five, even as the suite grew.

This is one company’s account, and some improvements would have been useful without AI. The transferable question is whether faster code and test generation has moved your team’s bottleneck into validation. Measure the time from a proposed change to trustworthy feedback, not just the time to generate the change.

In an IBM/Oxford Economics survey, 80% of HR leaders said AI creates work such as checking recommendations, correcting errors, supplying context, and handling exceptions. Meanwhile, 42% of employees said AI increases their work or leaves it unrecognized.

The survey captures perceptions; it does not measure how many extra hours AI caused. But it points to a blind spot for teams claiming productivity gains from faster first drafts. Someone still has to decide whether an answer is usable, repair mistakes, and take responsibility when the workflow reaches an exception. Count that work when evaluating the result.

The Model Context Protocol project finalized an extension on 13 September for servers to advertise and deliver agent skills to compatible clients. In principle, a team could maintain a reusable instruction once and make it available through more than one agent environment. That could reduce the work of rebuilding practices inside each tool.

But a finalized specification is not the same as broad support or effortless portability: clients must implement it, and a useful skill may still depend on a particular tool’s commands or permissions. If you are building a library of agent skills, separate the instructions that can travel from the assumptions tied to one environment.

This week, while building a conversational system that helps a user form an information request, I worked on a deceptively simple question: how should the system use what it already knows about that user?

Suppose someone has previously said they live in Pune. When they ask for theatre recommendations, that context may help. But a system that hands the entire user profile to every conversational step creates a different problem. It may expose irrelevant details, treat an old inference as a confirmed preference, or use information for a purpose the user never authorized.

The design we implemented uses a narrower path. The conversation can request context for specific needs, such as geography. A reader checks ownership, permission, and relevance before passing along only eligible evidence. The conversation then treats that evidence as a candidate: an inferred location remains inferred, and an unconfirmed detail cannot silently become a fact about what the user wants.

That boundary took more work than simply adding “user context” to a prompt. It also gives us a clearer way to test mistakes. Can one user’s information cross into another conversation? Can unrelated context appear? Can an inference acquire more authority as it moves through the system?

The lesson extends beyond this project: personalization is useful when a system knows both what context may help and where its authority ends. The implementation and its current limits are recorded in the context-provider change.

Read the developer’s original ZCode investigation if your team evaluates coding tools for private repositories. It shows the local snapshot records, the file list that exposed Git history, and how the upload workflow was traced. The later clarifications are especially useful: the large private archive did not upload successfully, while a smaller public-repository snapshot did.

The value is in the method as much as the incident. It shows how to ask what a tool collected, what it attempted to send, and what the available evidence actually proves—without treating an attempted transfer as a completed one.

If you use a coding agent on a private repository, take a few minutes to find out what it sends beyond the files needed for a request. Include Git history in that check; it can contain things the current checkout no longer shows.

Have you found a clear way to inspect or limit your coding tool’s repository uploads? Reply and tell me what worked—or where the answer was hard to find. I’d like to bring useful examples into a future issue.