Editor and workspace config

Check C13 · execution surface family · severity HIGH · automatic · one of the 22 checks

The question this check asks: does this repository carry editor configuration that can act the moment you grant Workspace Trust — a task that runs on folder open, a settings file that points your tools at its own binaries, a workspace file that overrides both?

Why it matters

A .vscode/tasks.json task with runOptions.runOn set to folderOpen executes the moment you click Trust. Jamf attributed an active DPRK-linked operation — Contagious Interview, repositories handed to job candidates as "technical assignments" — to exactly this file. The sibling risk is .vscode/settings.json, which can repoint an extension's interpreter or linter path at a binary committed in the repository, so that the first time your editor lints the code it runs the attacker's program. A .code-workspace file is a multi-root container for both, with its own settings that override the folder's. VS Code 1.109 turned automatic tasks off by default; the defence for everything else lives in user settings.

How RepoGates scores it

C13 reads the repository's file list — one API call, no clone — and fires on three paths, each at severity HIGH for 10 points: .vscode/tasks.json (“folderOpen tasks run on workspace trust”), .vscode/settings.json (“can repoint linter/interpreter binaries”) and any *.code-workspace (“multi-root workspace override”). A repository that trips nothing else scores 90, the badge stays green, the verdict is REVIEW, and the default personal policy warns. It never blocks on its own. The execution-surface evidence note in the scoring table:

“28.8% of top-100 repos carry devcontainers — informative, not damning”

False positives we know about

Most projects with a VS Code user among the maintainers. A settings.json that sets tab width and a tasks.json that defines a build task you run by hand are the common case, and both fire the same finding as a folder-open task, because the file list cannot tell them apart. The warning names the file; reading it takes a minute, and the two user settings below make the reading optional.

What this check does not cover

It sees the file, not its keys — runOn: folderOpen versus an ordinary task is a contents question, which a deep scan answers. It covers VS Code's files; JetBrains run configurations under .idea/, Sublime projects and other editors' equivalents are not on the list. And it fires at download time: the task runs when you open the folder and trust it, which is a step after the one RepoGates can see.

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.

Check it yourself

Without installing anything: open .vscode/tasks.json on GitHub and look for folderOpen; open settings.json and look for any key ending in Path that points inside the repository. With the GitHub CLI:

gh api repos/OWNER/REPO/contents/.vscode/tasks.json --jq .content | base64 -d | grep -n folderOpen
gh api repos/OWNER/REPO/contents/.vscode/settings.json --jq .content | base64 -d | grep -nE '(Path|interpreter|executable)"\s*:'

Then set the two things the standard puts in user settings — workspace settings are attacker-controlled — and never tick Trust all folders in the parent:

"task.allowAutomaticTasks": "off",
"security.workspace.trust.untrustedFiles": "newWindow"

Questions

My project ships a .vscode folder — is that a problem? Almost never, and most projects do. The finding costs 10 points and warns because the files can act the moment a folder is trusted: a task with runOn set to folderOpen executes then, and a settings.json can point the Python interpreter or a linter at a binary in the repository. The board names the file so you read it before clicking Trust.

Is there a setting that makes this go away? Two, both in your user settings — never in the workspace, which the repository controls. task.allowAutomaticTasks set to off, and security.workspace.trust.untrustedFiles set to newWindow. VS Code 1.109 turned automatic tasks off by default; older installs need the setting. And never tick Trust all folders in the parent.

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 task runs when you open the folder.

Related checks

C10 Devcontainer auto-execution — the same moment, one layer down · C14 Build scripts and wrapper JARs — what runs when the language server starts · C15 Committed binaries — the binary a settings file would point at.

Add RepoGates to Chrome Pricing

Numbers on this page: Jamf's attribution of Contagious Interview, and VS Code 1.109's default change, as cited in the repository vetting standard; weights and actions from the product's scoring and policy tables.