Veltron Research · 2026-08-29
What runs when you open a repository
You clone something, or an agent clones it for you, and you open it. Before you read a line, a task can fire, an agent hook can spawn a shell, an install script can run. We took the 10,000 most-starred public repositories on GitHub and scanned 9,997of them — three could not be fetched at all — to find out how often that is true. As far as we can tell, nobody had measured it.
La investigacion de Veltron se publica en ingles. El publico de este trabajo son las personas que clonan codigo que no escribieron, y esa conversacion ocurre en ingles.
Restricted to the 9,808 repositories the scan could read in full, the first figure is 24.6%. Both numbers are published because the gap between them is itself worth seeing.
Put the first and last figures next to each other and the shape of the problem appears. A repository picked at random from this set runs something 25.0% of the time. One that ships configuration for a coding agent runs something 62.3% of the time. That is the newest surface in the set and the most loaded one.
Where it concentrates
The more popular the repository, the likelier it runs something.
| Stars | Repositories | Execute something |
|---|---|---|
| 50,000+ | 483 | 36.9% |
| 20,000 - 50,000 | 1,760 | 30.6% |
| 6,045 - 20,000 | 7,754 | 23.0% |
Whatever this is, it is not something that only happens in neglected corners. It rises with attention. The most-starred band is the one most likely to run something when you open it.
Of the 6,995 repositories with a push this year, 874carry agent configuration — about one in eight. That is a cross-section, not a trend: pushed_at records the last push, so a repository untouched since 2020 could not have gained a file that did not exist yet, and reading the older years as a curve would be reading the definition back as a finding.
Share of repositories with at least one finding from each scanner family, at any severity.
Method
Nothing was cloned. Nothing was executed.
A study of what runs when you open a repository cannot be produced by opening ten thousand of them. So none were opened. The harness reads the search index, asks each repository for its file listing, downloads only the configuration files the scanner knows how to read, and scans those. Every file is fetched at a pinned commit, recorded alongside the result, so the same run months later reads the same bytes.
The findings come from Onopen, used as a library. The two calls the harness makes are the two calls the command-line tool makes, so every row in the dataset is what onopen --json prints for those files. Not one rule was reimplemented for the study.
Downloading part of a repository is only sound if the scanner reads that part the way it reads a clone. That is proven rather than assumed: the harness clones real repositories, scans the clone, and compares finding for finding against what it recorded. A single mismatch fails the check and blocks publication.
The harness and the full dataset are published — one line per repository, carrying the commit it was read at and every finding in it. The figures above are counts over that file, produced by a function in that repository. A number here that cannot be traced back to one is a number that should not have been printed.
What this number is not
A floor, and not an accusation.
It undercounts, and cannot overcount.
The study sees what is committed to the default branch. Live git hooks exist only in a working copy, so a repository that points core.hooksPath at a directory it ships is missed here. Nothing in the method can inflate the figure.
A finding is not a vulnerability.
A build script, a devcontainer, an install hook that compiles a native module — these are what those files are for. The finding is that the surface is large, that it grew a new limb in the last two years, and that almost nothing looks at it. This is not a list of projects doing something wrong, and it is not published as one.
Incomplete is never counted as clean.
GitHub caps very large file listings, some downloads fail, and some configuration files cannot be parsed by anything. That happened to 60 listings, 53 downloads and 81 repositories respectively. All of them are counted, kept out of the clean column, and reported here rather than in a footnote.
Check it yourself
Run it on your own repository.
The interesting question is not what the average repository does. It is what the one you are about to open does.
cargo install onopen --locked && onopen ./the-repoIt reads files and parses them. It never executes a command and never opens a network connection. Apache-2.0, and the findings above came from version 0.4.0.