Check C17 · execution surface family · severity MEDIUM · automatic · one of the 22 checks
The question this check asks: does this repository carry an .envrc — a shell script that direnv will source, as you, every time you enter the directory?
direnv is a convenience that many developers install once and never think about again: enter a project directory, and its .envrc sets up the environment. The file is bash. It can export a variable, and it can do anything else bash can do, and it runs on every cd for as long as the directory exists. direnv's own defence is that a new or changed .envrc is blocked until you type direnv allow — which is a real step, and also the step developers who use direnv perform by reflex, the way the rest of us click Trust. The vetting standard's summary is three words: arbitrary bash on cd.
C17 reads the repository's file list — one API call, no clone — and fires when .envrc sits at the root. The finding is MEDIUM, costs 5 points, and reads “arbitrary bash on cd (direnv)”. A repository that trips nothing else scores 95, the badge stays green, the verdict is REVIEW, and the default personal policy warns: the download is held, the finding is shown, proceeding is one click. It never blocks on its own; the direnv allow step is the reason it sits at the light end of the execution-surface family, whose evidence note in the scoring table reads:
“28.8% of top-100 repos carry devcontainers — informative, not damning”
Every project whose maintainers use direnv — common in Nix, Go and infrastructure repositories, where the file usually says use flake or exports a path and nothing else. The check cannot tell that file from one that curls a script, so it warns at five points and names the file, and reading it takes ten seconds.
It sees the file, not its lines; a deep scan reads them. It reads .envrc only — a .env file is data, not code, and is not flagged; shell configuration files a repository might ask you to source by hand are not on the list. It does not see whether you have direnv installed, and a machine without it is not exposed. And it fires at download time: the script runs when you enter the extracted directory and allow it.
And RepoGates as a whole gates browser downloads only — it does not see git clone, package managers, curl, or fetches made by AI agents outside the browser.
Without installing anything: open .envrc on GitHub and read it; it is usually a few lines. With the GitHub CLI:
gh api repos/OWNER/REPO/contents/.envrc --jq .content | base64 -dThen keep the habit that makes this check unnecessary: never direnv allow a file you have not read, and re-read it whenever direnv says it changed.
Does direnv not ask before running an .envrc? It does — a new or changed .envrc is blocked until you run direnv allow. That is exactly why the finding is 5 points and a warning rather than more: there is a step between the file and your shell. The risk is the reflex. Developers who use direnv type direnv allow the way they click Trust, and the file it allows is arbitrary shell that will run on every cd from then on.
Is an .envrc the same as a .env file? No. A .env file is data — key=value pairs a library reads. An .envrc is a shell script that direnv sources; it can export variables, and it can run anything else. The check reads only .envrc, because only .envrc executes.
Does RepoGates stop git clone? No. RepoGates gates browser-initiated downloads — Download ZIP and release-asset archives. It does not see git clone, package managers, curl, or fetches made by AI agents outside the browser. The finding fires at download time; the script runs when you enter the extracted directory and allow it.
C10 Devcontainer auto-execution — the same idea with no allow step · C16 Install scripts — code that runs at install rather than on entry · C11 Nested bare repository — the execution-surface finding that does block.
Add RepoGates to Chrome Pricing
Numbers on this page: weights and actions from the product's scoring and policy tables; direnv's allow model from its documentation.