The Context Debt Report · August 2026

We scanned 1,813 of the most-starred repositories on GitHub.
Here are the receipts.

Context debt: the expired code your AI reads — and you pay for — every day. Workarounds whose cited reasons died: the issue closed, the browser was dropped, the date passed, the version floor moved. This report has three parts — how much of it a normal project carries, the individual cases we were willing to put our name on, and what happened when we asked every cited issue whether it was still open. It also lists what we refuse to claim, and the things we got wrong. Every claim on this page is published as data at /claims.json and re-checked before every publish.

Part one: how much is normal

A self-admitted workaround is a comment where the code says so itself: workaround, hack, kludge, remove this once…, until we upgrade…. Density here is markers per 10,000 lines, so a 75,000-line project and a 1.7-million-line one can be compared at all. Across 201 million lines it is stable, and lower than most people guess.

Half of these projects carry fewer than one confession per 10,000 lines. 456 of them (25%) contain not a single one — the most misread number here. A large, old codebase with zero markers is not clean; it is quiet. Nobody wrote the label. The debt is still there, unsigned. At the other end, 96 repositories exceed 5 per 10k. Density measures how honestly a team writes things down, not how dirty the code is.

JavaScript confesses most often, PHP least. Comment culture differs by language and by project age — compare density within a language, not across.

The densest repository in the census was written by a machine

redash tops the list at 81 markers per 10,000 lines — 11× the 99th percentile. They are all the same line: // @ts-expect-error ts-migrate(7053) FIXME:. A TypeScript migration codemod stamped 609 identical confessions across the codebase in what was presumably a single afternoon. Real debt, but one decision — not 609 of them. This is why the median matters and the mean does not.

The numbers, per repository

Largest raw counts in the census — where an agent reading the code meets the most expired reasoning per task. Click a column to sort.

Part two: confirmed — the reason is dead, the code is alive

On hold: waiting for an event nobody subscribes to

What we refuse to claim

Precision beats recall. A false "expired" kills trust — so the report includes the findings we rejected, and why.

The 25 comments that named their own deadline — and missed it

A date inside a comment is the only expiry that needs no interpretation. The scanner found 25 across the census; we read every one by hand, and they do not all mean the same thing.

Part three: the reasons that already expired

A workaround that links an issue is a promise with an address on it — remove this when they fix it. That promise is checkable by machine, and almost nobody checks it. The corpus cites 978 distinct issues from inside 406 repositories. We asked every one of them.

Of the 956 references GitHub could resolve, 679 were closed as fixed — 582 of them at least a year ago. The median marker in this set is waiting on a fix that shipped 4.2 years ago; the oldest waits on one from 15.0 years ago. 204 cited issues are genuinely still open, and those workarounds are doing exactly what they say.

Closed is not the same as fixed, and we count it that way. A pull request closed without merging fixed nothing, and an issue closed as not planned is worse than unfixed — it means the workaround is now permanent rather than expired. 73 references fall into that category and are excluded from every number above. Building this pass without that distinction gave us 752 instead of 679, and we would have published it.

Nor is fixed the same as removable. Three things must be true before a line can go, and this pass establishes only the first: the fix has to exist, the project has to be on a version containing it, and removal has to be safe. That is why the scanner refuses to call anything expired until the lockfile agrees, and why the ten rows below were each read by hand.

The 949 markers pointing at a fixed issue split three ways, and they are not the same finding:

The oldest of all of them is both at once. Knockout carries // Workaround for .../knockout/issues/155 in src/virtualElements.js, citing an issue its own maintainers closed on 2011-09-13 — titled "comment-based control flow broken in IE7 after <li> tag". Magento 2 ships a bundled copy of that same file, so a fifteen-year-old sentence about Internet Explorer 7 is sitting inside a store checkout somewhere right now, still explaining itself to everyone who reads it, including your agent.

Ten of them, read by hand

Every row: the marker is in that file at upstream HEAD today, and the issue it cites was closed as fixed on the date shown. That is the whole claim. It is not a claim that the line should be deleted.

Three closed issues that prove nothing

Every claim here is re-checked, including against ourselves

A report is a set of statements whose reasons can expire — which is the exact thing this tool is for. So the cases above are not written once and left: each one is a machine-checkable claim (repository, file, the string that must still be there), re-run against upstream HEAD before every publish. The claims are published as data — claims.json — and the verifier that checks them is verify.py. Take both and re-run them against us; it needs git and nothing else.

Last re-verified 2026-08-30: 31 of 31 published claims still hold. Two did not survive the previous pass and were rewritten rather than quietly left: twenty had a second dated marker that has since been removed from main, and our webpack count was wrong — TODO webpack 6 appears 66 times across 37 files today, not the eight we first reported. When one of these is fixed upstream, it will be marked fixed here with the date, not deleted. A report that only grows is a report nobody re-read.

What this report does not say

None of this says the code should be deleted. A marker means the code admits it is a workaround; whether the reason expired is a second question and whether removal is safe is a third — WordPress core checks every request for Netscape 4 and cannot remove it, because its backwards-compatibility contract forbids it.

A closed issue is evidence, not a verdict. Part three establishes that a cited fix exists and when it landed. It does not establish that the project has upgraded to a version containing it, and it does not establish that removal is safe. Read those numbers as a list of questions worth asking.

The sample is biased on purpose. Most-starred repositories in four languages, deduplicated, restricted to at least 5,000 lines of scannable source so that awesome-lists and tutorial repos do not distort density. Popular open source is better maintained than average private code. Read these numbers as a floor.

Method

Repository list built from a public daily ranking snapshot, filtered to JavaScript, TypeScript, Python and PHP. Each repository was shallow-cloned, scanned with contextdebt 0.1.7, and deleted immediately: 3,239 clones attempted, 2,978 scanned, 1,813 met the 5,000-line floor. A marker counts only inside a real comment in that language's own syntax — identifiers, UI strings, PHP 8 attributes and docstring prose that merely describes behaviour are excluded, every one of those rules added after a false positive we published. Dates are compared to the scan date and require removal-intent wording nearby. Tier 2: issue links checked against their tracker; a closed issue is never sufficient on its own — the fix must be in the version the lockfile actually resolves. The same repository list was scanned a second time, six hours later, to capture every issue reference rather than a sample per repository; that pass returned 1,812 repositories, 200.5M lines and 25,489 markers. The 0.2% drift is repositories moving between the two clones. Parts one and two quote the first pass and part three the second; both are dated rather than quietly reconciled, because a number without a timestamp is the thing this report is about.

The scanner is free, has zero dependencies, and never sends your code anywhere: the only network call it can make is a GitHub API lookup for an issue number found in your own comments.