Check G13 · execution surface family · severity HIGH · automatic · one of the 22 GitLab checks
The question this check asks: does this gitlab.com project 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? It is C13, the GitHub check, run unchanged on a project hosted at gitlab.com.
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, and Microsoft's write-up of the same campaign on 11 March 2026 is explicit that the host does not matter: the candidate is told to clone and run a package hosted on GitHub, GitLab or Bitbucket, and once VS Code has been granted trust it "automatically executes the repository's task configuration file". GitLab's own threat-intelligence team banned 131 accounts in 2025 for North Korean nation-state malware distribution — the Contagious Interview recruiter lures — an average of eleven a month. The sibling risk is .vscode/settings.json, which can repoint an extension's interpreter or linter path at a binary committed in the project, 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.
G13 is C13 on a gitlab.com project: the same code, run on a snapshot RepoGates builds from gitlab.com's public API. The file list is one call — the recursive repository tree at per_page=10000, no clone; inkscape/inkscape's 7,182 entries arrive in 0.36 s. A full page is reported as truncated rather than read as complete, and a project with more than one page — twelve of the 100 most-starred, gitlab-org/gitlab among them at 136,997 entries — is a partial scan: the tree checks ran on the first page only, the verdict is cached briefly and retried, and it is never a clean PASS. On that list the check 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 project 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”
That note is GitHub's Phase 0 measurement. On 19 September 2026 the same code ran, anonymously, over the 100 most-starred gitlab.com projects: an auto-execution row of some kind — this one, a submodule, a wrapper JAR — was the sole reason for seven of the run's REVIEW verdicts, and no .vscode file changed a verdict by more than that warning.
Where the verdict reaches you today: the API (GET /v1/gl/score/{path}), the MCP server (check_repo with platform="gl"), and the Claude Code plugin's preflight (a hook on Claude Code's Bash tool: it reads the command line, never a process), which turns a warning into an ask before a git clone https://gitlab.com/… line runs. The extension's board on gitlab.com pages is a later release.
Most projects with a VS Code user among the maintainers, on gitlab.com as anywhere: four of the hundred most-starred carry a .vscode file. A settings.json that sets tab width and a tasks.json that defines a build task you run by hand fire the same finding as a folder-open task, because the file list cannot tell them apart. The finding names the file; reading it takes a minute, and the two user settings below make the reading optional.
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. GitLab's own Web IDE is not the editor this check is about: GitLab's documentation for it describes no task runner, and whether it acts on a tasks.json is not something we have verified — the editor on your machine is the one the lure targets. And the finding is on the verdict before the project reaches your machine; the task runs when you open the folder and trust it, a step after the one RepoGates can see.
And RepoGates as a whole is a browser download gate and an answer an agent can ask for: it does not see git clone, package managers or curl — outside Claude Code with the RepoGates plugin, whose hook refuses a clone or install that names a blocked repository on the command line, before it runs.
RepoGates runs the same 22 checks on a gitlab.com project that it runs on a GitHub repository, from gitlab.com's public API, under the key gl/{namespace…}/{project}. What that API withholds from an anonymous caller — fork status, a user namespace's account age, and OpenSSF Scorecard, which does not cover gitlab.com — is listed as not checked, never assumed. A self-managed GitLab is another hostname and is not assessed. The repository's code is not read on this tier: a PASS means the provenance and the declared execution surface are clean.
Without installing anything: open the file on gitlab.com — https://gitlab.com/NAMESPACE/PROJECT/-/raw/BRANCH/.vscode/tasks.json — and look for folderOpen; open settings.json the same way and look for any key ending in Path that points inside the project. With curl against gitlab.com's API, the project path and the file path both URL-encoded, so / becomes %2F:
curl -s 'https://gitlab.com/api/v4/projects/NAMESPACE%2FPROJECT/repository/tree?recursive=true&per_page=10000' | jq -r '.[].path' | grep -E '^\.vscode/(tasks|settings)\.json$|\.code-workspace$'
curl -s 'https://gitlab.com/api/v4/projects/NAMESPACE%2FPROJECT/repository/files/.vscode%2Ftasks.json/raw?ref=BRANCH' | grep -n folderOpenAnonymous gitlab.com allows 500 requests a minute from one address, and each line above is one. 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"My project ships a .vscode folder — is that a problem? Almost never, and many do: four of the hundred most-starred gitlab.com projects carry one. 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 project. The finding 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 project 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 of a gitlab.com project? In the browser, no: an extension cannot see a process outside it, and RepoGates does not see git clone, package managers or curl — outside Claude Code with the RepoGates plugin, whose hook refuses a clone or install that names a blocked repository on the command line, before it runs. This finding warns rather than blocks, so a clone of a project that carries it becomes an ask there, not a refusal. A browser gate for gitlab.com's own download links is a later release; the task runs when you open the folder and trust it.
C13 Editor and workspace config — the GitHub original · G10 Devcontainer and Workspace devfile auto-execution — the same moment, one layer down, plus the devfile GitLab's own Workspaces run · G14 Build scripts and wrapper JARs — what runs when the language server starts · G15 Committed binaries — the binary a settings file would point at.
Add RepoGates to Chrome Pricing
Numbers on this page: the 100 most-starred gitlab.com projects, measured 19 September 2026 through the same code as the verdict API; Microsoft's Contagious Interview write-up of 11 March 2026 and GitLab's threat-intelligence post of 19 February 2026; Jamf's attribution 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.