Where Your Code Goes: A Census of Agent Data Terms

Coding agent data retention is the question every procurement review, privacy assessment and engineering lead eventually asks — and the answers are scattered across dozens of vendor pages that do not use the same words, cover the same tiers, or in some cases exist at all. This census puts six fixed questions to seventeen coding agents and harnesses, using only each vendor’s own published documentation, and reports every cell — including the ones that would not resolve.

The six questions: does repository content leave the local machine in normal operation; what is the stated retention period, by plan tier; is content used for model training by default, and at which tier can you opt out; is a zero-data-retention arrangement published, and for whom; is telemetry separable from code content, with the setting name; and where do the terms actually live. All answers reflect vendor documentation as retrieved on August 17, 2026.

What follows is the method, a status vocabulary that keeps unanswered cells honest, the complete 17-row table, and the patterns the table supports — plus, just as deliberately, the inferences it does not.

Nobody buying or auditing a coding agent in 2026 reads one privacy policy. The sources scored in this census include consumer policies that exclude the product’s business tier, enterprise FAQs, security pages, a trust-center document, developer docs and a terms index — and the documents rarely agree on vocabulary. In the sources this pass checked, we could not find any vendor or third party publishing these answers side by side across the category at this width, with one method and one date.

The table records what is documented, and says so plainly, for a specific reason: documented behaviour is not verified behaviour. Our wire-level look at the July 2026 Grok Build incident established that a documented, user-facing privacy control and an actual data flow can diverge — that story is told in full there and is not re-argued here. It is simply the reason this census claims only what vendor pages say, and never presents a published policy as a tested one.

One more reason a dated snapshot matters: these terms sit under companies whose ownership is itself in motion. Cursor’s parent Anysphere became a SpaceX subsidiary when the acquisition closed on August 14, 2026 — covered separately in our read of the close and its first product move — and a policy retrieved before an ownership change is not evidence about the policy after it. Every cell below carries its retrieval date for exactly that reason.

The value of a census is that the gaps are as informative as the answers — but only if the gaps are classified honestly. A page that was read and did not answer, a page that could not be located, and a page whose answer our tools could not render are three different findings, and conflating them would be unfair to vendors and would discredit the table on first inspection. The full method and its known limits:

Every cell in the table carries one of six statuses, and the distinction between the last three is the part most comparisons skip:

The table below is the asset — all 17 rows, no summary substitution. Product names link to the primary source each row was scored against (question six of the census). Cells marked UND, JS-gated or N/L follow the status vocabulary above. Data as of August 17, 2026, retrieved from vendor-owned pages only.

Two rows share one structural carve-out worth reading together: Anthropic’s provider-level “Covered Models” safety retention (rows 1 and 12) applies wherever those models are served — Zed states plainly that switching to your own API key does not avoid it. We covered the one Claude model tier where zero data retention does not apply in full when the policy landed; the census simply records it as the clearest example of a retention rule that no downstream vendor’s terms can override.

Eight of the 17 rows are flagged unresolved: Kimi Code, Qwen Code, Z.ai’s GLM Coding Plan, GitHub Copilot, Grok Build, DeepSeek Harness, Continue and Aider. In each case the page that should carry the answer could not be located, could not be read, or disclaims the product it was supposed to cover — or a check the method specified was not run. Publishing them unresolved, with the reason classified, is the point: a census that quietly filled these cells by inference would be worthless to exactly the procurement and research readers it exists for. They fail in four ways, three of the eight in two ways at once, and the four support very different conclusions:

One clarification the count needs, because a reader checking it will find this immediately: individual UND cells are far more common than those eight rows. On most of the remaining rows — Cursor, Cline, Google Antigravity, Amazon Q Developer and Tabnine among them — a page was reached and read in full and simply does not address one sub-question, usually an exact retention day-count. Those are marked in place, cell by cell, rather than counted as unresolved rows, because a page that was read and did not answer is a different finding from a page that could not be reached, could not be rendered, or disclaims the product. Only one row, Zed, carries no open marker of any kind.

The single most practical pattern in the table: where a training-by-default answer exists at all, it almost never has one value per vendor. It has one value per plan tier — which means every unqualified sentence of the form “vendor X trains on your code” is incomplete, and sometimes wrong, for the tier you are actually on. Three vendors document the pattern explicitly:

The counts, stated with their denominators rather than rounded into “most vendors”: of 17 rows, 14 had a working, product-specific privacy or data-handling page; 3 (Kimi Code, Qwen Code, Z.ai’s GLM Coding Plan) had none this pass could locate; 8 are flagged unresolved. Where ZDR is published at all, it is consistently gated to team, enterprise or approval-based tiers requiring explicit administrative action — this census found no row where zero data retention is a default consumer-tier state.

The two clearest documenters in this census were not the two largest vendors. Tabnine publishes the most granular no-train-no-retain language in the set — context “deleted immediately after the server returns the answer,” even for on-premises and VPC Enterprise deployments, with a separate, numeric one-week window for non-code operational telemetry, the only telemetry day-count found anywhere in the census. Zed names the single exception to its own zero-retention default without hedging, states who imposes it (the model provider), and says plainly that it cannot opt out. Meanwhile Cursor and current-era GitHub Copilot — both far larger companies — publish no exact retention day-count for their standard tiers anywhere this pass could reach.

Grok Build’s enterprise deployment doc deserves its own mention as the best-organized data-lifecycle description in the set: a documented six-phase flow ending with “no prompts, code, or responses are persisted at the inference layer” for ZDR organizations. The same vendor’s enterprise FAQ, one directory over, is JS-gated and stamped with a date that predates the product. Both facts are in the table; a census that kept only one of them would be marketing.

One structural date matters more than any single vendor’s prose: GitHub’s Copilot-specific product terms were formally deprecated on March 5, 2026, replaced for Business and Enterprise direct-from-GitHub purchases by the general GitHub Customer Agreement plus a product-agnostic Data Protection Agreement. Any description of “Copilot’s data terms” written before that date — including the archived promise that prompts are “deleted once Suggestions are generated” — is describing a superseded document.

For procurement and security reviews, the table is raw material, not a verdict. Three usage rules keep it honest. First, always carry the tier: a retention or training answer without its plan tier is a different (and usually wrong) claim, so match the row’s tier language to the tier you are actually buying. Second, treat unresolved cells as questions to put to the vendor, not as answers — the rows marked JS-gated in particular likely have published answers a human can reach in a browser session. Third, remember what a documentation census cannot tell you: whether the documented control governs the actual data flow. That last question is answerable only by testing, and this census deliberately does not claim to have done it for any row.

The natural companion piece is the procurement questions this table is built to help you ask — the census supplies the documented baseline per vendor, the checklist turns open cells into contract questions. Teams that want help running this kind of evaluation against their own shortlist and tiers can look at our AI transformation engagements, which start from exactly this documented-versus-verified distinction.

Looking forward, two things seem likely to change fastest. The three rows with no locatable policy page can each be fixed by a vendor shipping a single URL — so those cells may be the shortest-lived findings here, and re-running the census against them is cheap. And the ownership churn around these products — one census vendor changed parent companies three days before this data was retrieved — can move terms without moving URLs, which is why the as-of date travels with every figure rather than sitting in a footnote.