Your Git history is already in the cloud

ZCode transmits your Git history to a cloud service. The transmission occurs without a user action to start it and without a notification to confirm it. That is the finding. It is not a feature description and it is not a warning about future risk. It is present behavior, and everything in this briefing traces back to it.

This is a privacy violation because local repository data crossed a trust boundary the user did not authorize. The local development environment is a controlled space. Data inside it belongs to the user and stays under the user’s control until the user decides otherwise. Identity is the boundary. When repository data leaves the device with no authorization event from the person who owns it, that boundary has already been crossed by the time anyone could object. Control is not weakened here. Control is absent at the point it was supposed to apply.

The scope of what is confirmed is narrow, and that matters. Confirmed: ZCode silently uploads Git history to the cloud. Not confirmed: the destination endpoint, who can read the data once it arrives, how long it is retained, whether transmission is encrypted, how often it runs, and whether it can be disabled. These are not omissions to be filled with reasonable assumptions. Absence of that data is a condition. Treat it as one. The behavior is established. The surrounding parameters are not.

What is externally observable is a state change in the location of the data. Git history that exists on the local machine appears at a cloud service. The movement happened. No upload command was issued by the user to cause it. No consent prompt preceded it. No notification followed it. The observable sequence is data at rest on the device, then data transmitted off the device, with no user-facing event between those two states. Nothing the user did and nothing the user was shown accounts for the transition.

What failed is the boundary between the local repository and external infrastructure. Movement of repository data off the device is an event that should require an authorization gate. In the observed behavior, no such gate is visible. The data moved. Whether the internal logic of ZCode routes, batches, or schedules that movement is not confirmed, and it is not the point. The point is the externally observable outcome: local repository data left the machine and reached a cloud service, and the user’s authorization was not part of that path.

Git history, as a data class, records commit authorship, timestamps, commit messages, and the content of tracked changes. That is what the object is, independent of ZCode. The specific records transmitted from any given repository are determined by that repository and are not confirmed here. What is confirmed is the class of data in motion. A tool moving that class of data off the device without an authorization event is not moving a neutral artifact. It is moving the recorded work, identity markers, and change content held in the repository, and it is doing so outside the user’s decision.

The behavior failed because the data left without a user action, which means any control positioned to require consent before transmission did not stop the transmission. If such a control existed, it did not enforce, and a control that does not enforce is ineffective. State it plainly. If no such control existed, the boundary was open by construction and there was nothing to enforce. The facts confirm the outcome. They do not confirm which of these two conditions produced it. Both reduce to the same operator-relevant state: repository data can leave the device without user authorization.

The silence is the property that makes this a failure rather than a setting. A privacy control depends on the user knowing data is moving and being able to stop it. Silent transmission removes both. The user cannot deny what they are not asked. The user cannot revoke what they are not told is happening. The observable behavior confirms both conditions are met: no prompt before, no notice after. Consent that is never requested is not consent, and control that is never surfaced is not control.

Holding the discipline on what remains unknown keeps this accurate. Not confirmed: the destination of the transmitted history, the retention period at that destination, the access controls applied to it there, whether the data is encrypted in transit or at rest, whether the behavior can be turned off through configuration, and how many repositories are subject to it. Each of these is a condition, not a gap to be resolved with a plausible guess. The confirmed fact is bounded and specific. ZCode uploads Git history to the cloud, silently, without user authorization. That is what failed and why. What it exposes and what must now change is the next matter.

The mechanism is the absence of an authorization gate on an off-device transmission path. Repository data at rest becomes repository data in transit, and nothing in the observable sequence requires a user decision to permit that transition. The mechanism is not the upload itself. The mechanism is that the upload path is reachable from a state in which the user has authorized nothing. Whatever internal routing ZCode performs is not confirmed and is not the mechanism. The externally observable mechanism is a data-movement action that executes with no enforcement point in front of it.

Silence is the second half of the mechanism. Two detection surfaces exist for catching an off-device transmission: a prompt before it happens and a notice after it happens. The observed behavior removes both. With no prompt, the user has no decision point at which to deny. With no notice, the user has no signal from which to detect and revoke. The mechanism therefore fails in two independent places at once. It does not stop the movement, and it does not report the movement. A single missing gate is a control failure. A missing gate combined with a missing signal is a control failure the user cannot observe, which is the stronger condition.

The mechanism does not depend on intent, destination, or frequency, none of which are confirmed. It depends only on the reachability of the transmission path from a non-authorized state. That is what makes it a mechanism and not an incident. An incident is a single occurrence. A reachable unauthorized path is a property of the system that produces the outcome whenever the path is exercised. If a system allows repository data to leave without authorization, that data will leave without authorization. The observed behavior is the property expressing itself, not a one-time event.

The pattern this exposes is that a trust boundary which is not enforced at the point of crossing is not a boundary. The local environment was treated as controlled space. The mechanism shows the space is controlled only as far as enforcement extends, and enforcement did not extend to the transmission path. A boundary defined by expectation and not by an enforcement point exists in description only. The data confirmed this by crossing it.

The same mechanism generalizes to any capability inside a trusted environment that can move local data outward with no authorization event in front of it. The specific data class here is Git history. The mechanism does not care about the data class. Any tool granted execution context inside the local environment can reach the same outward path, and if that path has no gate, the class of data it carries is irrelevant to whether it leaves. The exposure is not “ZCode reads Git history.” The exposure is that a resident tool can move local data off the device and the user’s authorization is not on the path. Git history is the instance. The unauthorized outward path is the pattern.

Silent-by-default behavior compounds the pattern because it defeats the only user control that survives the missing gate, which is observation. When the gate is absent, detection is the fallback. When the signal is also absent, the fallback is gone. A user operating under the belief that local data stays local holds that belief indefinitely, because the system produces no event to correct it. The pattern is a trust relationship that continues to be extended to a tool that has already acted outside it, with nothing in the observable behavior to revise that trust. Trust that is never re-validated was not earned. It was assumed and never checked.

Reduce it to the operator-relevant state. Local repository data can leave the device without user authorization, and the user is neither asked nor told. Every surrounding parameter stays unknown. Destination not confirmed. Retention not confirmed. Encryption in transit or at rest not confirmed. Access at the destination not confirmed. Whether the behavior can be disabled not confirmed. Those unknowns do not reduce the severity. They define it. A transmission you cannot see, to a destination you cannot name, retained for a period you cannot bound, is not a managed risk. It is an uncontrolled one.

What must now be true is narrow. Movement of repository data off the device must pass through an authorization event owned by the user, and that event must occur before transmission, not after. A control that requests or reports consent after the data has left is describing history, not enforcing a boundary. If ZCode cannot demonstrate that gate, the correct operating assumption is that the gate does not exist, because the observed behavior is indistinguishable from a system that has none. Absence of a visible control is treated as absence of the control.

The finding does not soften with familiarity. A tool that transmits recorded work, authorship, and change content off the machine without asking and without telling has already defined its relationship to that data, and it is not a relationship the user authorized. Identity is the boundary, and the boundary was crossed before the user had the option to hold it. Until an enforced, pre-transmission consent gate is confirmed present, the only accurate statement about ZCode’s handling of Git history is the one the behavior already made. It leaves when the tool decides, not when the user does.