Inside The Machine

Authored by Neal Lloyd · Daily AI Series

Inside The Machine

Issue 38 · AI Corner · Inside The Machine

Day 38

Coding Agents · Telemetry · What Actually Leaves Your Machine

What Your Coding Agent Actually Sends Home
Independent Research Found a Popular AI Coding CLI Uploads Entire Repositories During Agent Sessions — Not Just the Files It Reads and Edits. Here Is the Real Distinction Between Working Context and Telemetry Footprint, and What to Actually Check.

Ground Truth, Episode 28, flagged this week’s finding that a popular AI coding CLI uploads entire repositories to cloud storage during agent sessions, discovered through independent wire-level research. This series takes the technical question underneath the headline: what should a developer actually expect an AI coding agent to send outside their machine, and how does that differ from what most people assume based on how these tools are marketed? Day 38 draws the line between an agent’s working context and its telemetry footprint, and explains why the gap between them matters most exactly where it is least visible.

Neal Lloyd

Author · Inside The Machine · July 2026

12 min read

Most developers running an AI coding agent have a working mental model of what it does: it reads the files relevant to the task, edits them, and moves on. That model is a reasonable guess and, this week, in at least one widely used tool, an incorrect one. The gap between the reasonable guess and the actual behaviour is not a hypothetical risk. It is the specific thing independent researchers just measured.

Neal Lloyd · Inside The Machine, Day 38

Ground Truth Episode 28 covered a supply-chain hit landing this week: independent wire-level research found that a widely used AI coding CLI uploads entire repositories to cloud storage during agent sessions, not just the files the agent actually touches as part of a task. This series will not walk through the specific research method used to confirm that, since the finding itself has protective value and the method does not. What this series will do is explain the underlying distinction that made the finding surprising in the first place: the difference between what an agent needs in its working context to complete a task, and what a tool actually transmits outside the user’s machine while doing it. This is Day 38 of Inside The Machine.

Section I — Working Context vs. Telemetry Footprint

What an Agent Needs to Finish the Task Is Not What It Actually Sends

A coding agent’s working context is the information it actually needs, at any given moment, to reason about the task in front of it — typically the specific files being edited, some surrounding files for reference, and recent conversation history. That is the mental model most developers reasonably hold: the agent looks at what is relevant, works with it, and the tool’s footprint on the developer’s system roughly tracks the task’s actual scope.

Telemetry footprint is a separate, broader category: everything a tool actually transmits outside the user’s machine, for any purpose — usage analytics, error reporting, session logs, and in some architectures, data collected for future model training or debugging. Some telemetry is disclosed clearly in a tool’s privacy policy and reasonably scoped to what it claims to collect. Some is not, or is scoped far more broadly than a reasonable reading of the tool’s marketing and documentation would suggest to a typical developer installing it.

This week’s finding sits squarely in that second category: a coding CLI whose working context, by any reasonable task-scoped definition, would be the specific files an agent is editing, was found uploading entire repositories — a telemetry footprint dramatically larger than the working context the tool’s use case implies. That gap between the two is precisely the thing worth checking for in any AI coding tool before pointing it at code that matters.

⚡ Before You Point an Agent at Sensitive Code

Read the tool’s data handling and telemetry documentation, not just its feature marketing. Check whether the vendor discloses what data leaves your machine and where it goes. Test with a disposable, non-sensitive repository first if you are uncertain. Prefer tools from vendors with clear, specific data-handling commitments over vague assurances of “privacy-first” design.

Section II — Why Broad Telemetry Happens, Even Without Bad Intent

The Path of Least Engineering Resistance Is Usually “Send Everything”

An AI coding agent genuinely does benefit from broader context in many legitimate cases — understanding how a file relates to the rest of a codebase, catching a naming convention used elsewhere, or avoiding a change that would break something in a file the agent was not explicitly asked to touch. There is a real engineering argument for giving an agent more context than the absolute minimum, and reasonable products draw that line in different, defensible places.

The problem is that from an engineering standpoint, uploading everything is simpler to build than uploading precisely the right subset, and that simplicity bias tends to push implementations toward broader footprints by default rather than narrower ones, especially under normal product-development time pressure. A team shipping a coding CLI on a deadline has every incentive to reach for the broad, simple version of context-gathering and comparatively little incentive to invest in the more careful, narrowly-scoped version, unless a specific customer requirement or security review forces the issue.

None of this requires assuming bad intent on any vendor’s part. Broad telemetry footprints are frequently the predictable output of ordinary product engineering incentives, not a deliberate decision to overreach. That is precisely why this is a governance and disclosure problem more than a trust-the-vendor’s-intentions problem: the fix is not assuming good faith, it is verifying actual behaviour, because good faith and broad data collection are not mutually exclusive.

Nobody has to be malicious for a tool to overreach. Broad data collection is very often just the easier thing to build, and easier tends to win under deadline pressure unless something external — a customer, a regulator, an independent researcher — forces the narrower, harder version instead.

Neal Lloyd · Inside The Machine, Day 38

Section III — What to Actually Verify Before You Trust a Tool

Documentation Is a Claim. Behaviour Is What Actually Matters.

A tool’s documentation and privacy policy describe what the vendor claims it does. Independent, empirical verification of actual network behaviour is the only way to confirm what a tool actually does, and this week’s finding is a reminder that the gap between those two things can be substantial even for widely used, reputable tools built by well-resourced companies. This is not a reason for blanket distrust of the entire category — it is a reason to treat vendor claims as a starting point rather than a verified fact.

For most individual developers, the practical version of this is not running your own network traffic analysis on every tool you install — that is neither realistic nor necessary for most use cases. It is a matter of proportional caution: for low-stakes, non-proprietary code, the default trust most developers extend to mainstream tools is reasonable. For genuinely sensitive codebases — proprietary algorithms, code under strict contractual confidentiality, anything covered by regulatory data-residency requirements — the calculation changes, and waiting for independent verification, or commissioning it, before adopting a new coding agent is the more defensible default.

Organisations with real security functions should treat this the way any other vendor risk assessment works: request specific documentation of data flows, ask direct questions about telemetry scope before procurement rather than after deployment, and build periodic re-verification into vendor management rather than treating an initial security review as permanent. Tools change their data practices over time, sometimes without prominent notice, and a one-time approval is not the same thing as ongoing assurance.

A privacy policy is a promise. Independent verification is the only thing that tells you whether the promise is being kept. Most developers extend trust based entirely on the former, because checking the latter is genuinely inconvenient — right up until the week an independent researcher does the checking for everyone else.

Neal Lloyd · Inside The Machine, Day 38

— Neal Lloyd
Inside The Machine, Day 38 · July 20 2026

← PreviousDay 37: What It Actually Means to Mathematically Prove Code Is Correct

Next →Coming Soon

About The Author

Neal Lloyd

Author · Series Creator

Authored by Neal Lloyd

Neal Lloyd writes about technology, human adaptation, and the uncomfortable questions nobody wants to answer at dinner. Inside The Machine is his ongoing daily series on AI.

By The Numbers

Distinct concepts this series draws a hard line between: working context (what a task needs) and telemetry footprint (what actually leaves the machine).

AI coding tool configuration types targeted in the separate npm supply-chain incident covered in Ground Truth Episode 28: Claude Desktop, Cursor, Windsurf, VS Code, and Zed.

Day 35

Where this series first covered a real, patched vulnerability at the responsible reporting level — facts and remediation, not exploit mechanics — the same standard applied here.

The Series

Key Concepts

Working Context

The information an AI coding agent actually needs to reason about a given task, typically the specific files being edited plus limited surrounding reference material.

Telemetry Footprint

Everything a tool actually transmits outside the user’s machine for any purpose, which can be substantially broader than its working context.

Simplicity Bias

This series’ term for the engineering tendency to build the broader, simpler version of data collection by default, absent a specific requirement forcing a narrower design.

Vendor Claim vs. Verified Behaviour

The distinction between what a tool’s documentation says it does and what independent, empirical testing confirms it actually does — the gap this week’s finding exposed.

Proportional Caution

This series’ recommended approach: default trust for low-stakes code, independent verification or delayed adoption for genuinely sensitive or proprietary codebases.

Inside The Machine

An ongoing daily editorial series on artificial intelligence.

Authored by

Neal Lloyd