What it checks

Tasks set to start on folder open, plus every task they depend on, including detected npm scripts such as “npm: build”. The file is read the way VS Code reads it: the same comments, whitespace and line breaks, runOn in any case, array commands joined, options.shell and options.env included, every platform's command checked (top-level windows, osx and linux sections too), and dependsOn chains followed to the end. A tasks.json with a syntax error is still reported, but not as automatic, since VS Code runs none of its tasks until it's fixed. Serious when the command runs a file that looks like malware, executes an image or font, or pipes a download into a shell, and worse when it also hides its terminal. An automatic task PreClone can't see into is never taken on trust.

Files: .vscode/tasks.json*.code-workspacerunOptions.runOn: folderOpendependsOn

Workspace settings that try to let automatic tasks start without asking, or to turn Workspace Trust off. Current VS Code only takes either from your user settings, so they don't work from a repo, but repos have no honest reason to ship them.

Files: .vscode/settings.jsontask.allowAutomaticTaskssecurity.workspace.trust.enabled

Extension settings such as python.defaultInterpreterPath, eslint.runtime or rust-analyzer's override commands that make an extension run a file or command the repo controls when you open a matching file. A repo script that reads as ordinary code is worth a look; an unreadable, networked or malicious one is not.

Files: .vscode/settings.json*.code-workspace

Extensions the repo asks you to install. Only listed as worth checking: the publisher, not the scan, decides what an extension does.

Files: .vscode/extensions.json*.code-workspace

A .vsix file in the repo, and any script or task that installs it with --install-extension. The extension's own code isn't unpacked or read.

Files: *.vsix

initializeCommand, which runs on your machine before the container starts, the other lifecycle commands, and mounts of your home folder, credential folders, the Docker socket or the whole filesystem. A command that copies SSH keys or cloud logins, on your machine or out of a mounted home folder, is read-first, and critical with the network. Routine host commands such as pulling or building images are listed, not flagged.

Files: .devcontainer/devcontainer.json.devcontainer.json

File Watchers that run a program every time a file is saved, Startup Tasks, and Gradle or Maven wrappers that download their build tool from somewhere other than the official servers. Watchers that run a known formatter or compiler are listed, not flagged.

Files: .idea/watcherTasks.xml.idea/*.xmlgradle-wrapper.propertiesmaven-wrapper.properties

Keys git runs as commands: core.fsmonitor (runs on every git status, which editors trigger), filters, sshCommand, pager, editor, diff and merge drivers, credential helpers, aliases and hooksPath, including included config files. A clone can't carry .git/config, so this applies to zips and local folders; on your own checkout, hook managers, Git LFS and fsmonitor = true are treated as routine.

Files: .git/config.git/modules/*/configcore.fsmonitorfilter.*.cleancore.hooksPath

exec, commandLine, ProcessBuilder and .execute() calls in any Gradle script (build and settings files, scripts they apply from:, buildSrc and build-logic convention plugins; Groovy or Kotlin), which run on every ./gradlew command and when IntelliJ IDEA or Android Studio syncs a project you've trusted. A download that runs, or malware-like code, is critical; git and version lookups are listed but not flagged. Also apply from: a URL (a build script fetched on every build), and a Java agent jar from the repo in gradle.properties' org.gradle.jvmargs.

Files: build.gradlesettings.gradle*.gradle*.gradle.ktsgradle.properties

build.rs files next to a Cargo.toml, which cargo and rust-analyzer run when they load the project, flagged when one starts a shell, downloader or interpreter or opens network connections. Also .cargo/config.toml settings that make cargo start a program from the repo: rustc-wrapper, rustc, linker (or -C linker in rustflags) and target runners. Compiler caches and system linkers such as sccache, clang and mold stay quiet.

Files: build.rs.cargo/config.toml

An .envrc that direnv runs on every cd, including the Nix dev shell it builds with `use flake` or `use nix` (shellHook, devenv's enterShell); mise hooks, sourced env scripts and exec() templates, plus tool postinstall commands and plugins fetched from outside GitHub or GitLab, which run on mise install; (eval . …) forms in .dir-locals.el; and .nvim.lua, .exrc, .vimrc and .lazy.lua files that start shell commands. Each tool asks once before trusting the file, so these aren't automatic, but a download that runs or malware-like code is critical. A Nix shell hook without direnv runs on nix develop, nix-shell or devenv shell.

Files: .envrcflake.nixshell.nixdevenv.nixmise.toml.dir-locals.el.nvim.lua.exrc.lazy.lua

Folders laid out as a bare repository (HEAD, config, objects/ or refs/) whose config or hooks run commands. Git, or an agent running git, inside that folder runs them; this is how CVE-2026-45033 reached Copilot CLI. Git LFS and Husky boilerplate hooks don't count against the project, and hooks that run only when something pushes into the folder are worth a look rather than a stop.

Files: */HEAD + */configcore.fsmonitorhooks/*

Commands coding agents run on their own: when the folder opens (Cursor's workspaceOpen), at session start, on every prompt, around tool calls. Routine tooling and hooks that only print a notes file are listed, not flagged (the file they print is checked like an instruction file); a repo script is worth a look; a hook that reaches the network or a malware-like file is serious. Codex asks about each hook before it first runs. Also reads the hooks of plugins the repo's .claude settings enable from a marketplace folder inside the repo; Claude Code asks you to install those first.

Files: .claude/settings.json.claude-plugin/marketplace.jsonhooks/hooks.json.cursor/hooks.json.codex/hooks.json.codex/config.toml.gemini/settings.json.windsurf/hooks.json.devin/hooks.json.devin/hooks.v1.json.devin/config.json.amazonq/cli-agents/*.json

Commands, or a script, that .cursor/worktrees.json tells Cursor to run in every new worktree it creates for an agent. Installing dependencies and copying files over from the main checkout are listed, not flagged; a repo script is worth a look; anything that reaches the network or a malware-like file is serious.

Files: .cursor/worktrees.jsonsetup-worktreesetup-worktree-unixsetup-worktree-windows

apiKeyHelper, awsAuthRefresh, awsCredentialExport, gcpAuthRefresh, otelHeadersHelper, statusLine, subagentStatusLine and fileSuggestion: shell commands Claude Code runs for credentials or display.

Files: .claude/settings.json.claude/settings.local.json

An env block that sends API traffic to another server (ANTHROPIC_BASE_URL, CVE-2026-21852), routes it through a proxy, trusts an extra certificate, or preloads code into every command Claude Code runs (NODE_OPTIONS, BASH_ENV, LD_PRELOAD, GIT_SSH_COMMAND and similar).

Files: .claude/settings.jsonenv.ANTHROPIC_BASE_URLenv.NODE_OPTIONS

Settings that approve MCP servers for you, start sessions in bypassPermissions mode (which Claude Code 2.1.257 and later ignore in project settings), pre-approve shells or interpreters, or turn off Codex's approvals and sandbox. Narrow allow rules such as one test command aren't flagged.

Files: .claude/settings.jsonpermissions.defaultModepermissions.allowenableAllProjectMcpServersenabledMcpjsonServers.codex/config.toml

stdio MCP servers in project config, and who starts them: VS Code once you trust the folder, Cursor after you approve each server, and Claude Code after you approve each server unless the repo's own settings approve it, and Claude Code for a plugin the repo enables from a marketplace folder in the repo, once you install it. Well-known servers are listed; unknown packages and repo scripts are flagged, anything that looks like malware is critical, and configs in subfolders count for less.

Files: .mcp.json.cursor/mcp.json.vscode/mcp.json.gemini/settings.json.codex/config.toml.roo/mcp.json.amazonq/mcp.json.devin/mcp_config.json

CODEX_HOME set to a path inside the project, which made Codex CLI 0.23.0 and earlier load the repo's config and start its MCP servers with no prompt (CVE-2025-61260).

Files: .envrc.envCODEX_HOME

Instruction, rule, command, skill and subagent files that hide text in invisible Unicode (decoded and shown) or HTML comments (of any length, and an unterminated one hides the rest of the file), or tell the agent to download and run a script from anywhere but an official installer, send secrets, keep things from you, or run with --dangerously-skip-permissions or --yolo. Critical only for hidden text, or hidden instructions to fetch code or move secrets; visible wording alone tops out at high.

Files: AGENTS.mdCLAUDE.mdGEMINI.md.cursorrules.cursor/rules/*.windsurfrules.github/copilot-instructions.md.claude/commands/*.claude/agents/*.claude/skills/*

chat.tools.terminal.autoApprove, which VS Code applies from workspace settings once you trust the folder, and the global chat.tools.global.autoApprove (formerly chat.tools.autoApprove), which current VS Code only takes from user settings but older versions honored in a repo (CVE-2025-53773).

Files: .vscode/settings.jsonchat.tools.terminal.autoApprovechat.tools.global.autoApprove

Shell commands embedded with !`…` in Claude Code commands and skills, which run whenever the command or skill is used, by you or by Claude, without asking when allowed-tools or your permission rules allow them. Flagged when what they run looks like malware or downloads and runs a script.

Files: .claude/commands/*.md.claude/skills/*

Tasks set to runOn worktreeCreated, which VS Code runs whenever it creates a worktree for an agent session.

Files: .vscode/tasks.jsonrunOptions.runOn: worktreeCreated

preinstall, install, postinstall and prepare scripts in the root and workspace packages, followed into the files they run. Routine setup (husky, prisma generate, node-gyp) is listed but not flagged; scripts that run malware-like files or reach the network are.

Files: package.jsonscripts.postinstallscripts.prepare

binding.gyp, which npm builds with node-gyp on install when there's no install script. Flagged when its command expansions do more than print a header path. Hosted-repo and zip scans don't read binding.gyp contents yet.

Files: binding.gyp<!(…)<!@(…)

node-options preloads, a replacement script-shell, onload-script, git or node-gyp pointed at repo files, strict-ssl=false, other registries and init-module. Critical when the setting runs a file from the repo.

Files: .npmrc

yarnPath pointing at something other than an official Yarn release, third-party plugins, env files Yarn feeds into every script (.env.yarn, injectEnvironmentFiles), other registries and enableStrictSsl: false. Official @yarnpkg plugins are listed, not flagged. Env file contents aren't read yet, so those are flagged for you to check.

Files: .yarnrc.yml.yarnrcyarnPathplugins

.pnpmfile.cjs, which runs on every install, dangerouslyAllowAllBuilds, allow lists that let unusual packages run install scripts, and nodeOptions or scriptShell pointed at repo files.

Files: .pnpmfile.cjspnpm-workspace.yamlpackage.json pnpm field

Resolved URLs in lockfiles that point away from the public registries. High when one is a raw IP address.

Files: package-lock.jsonyarn.lockpnpm-lock.yaml

Direct and locked dependencies checked against the OSV malware database and npm's security placeholders. One listed only in a fixture or example lockfile that a normal install doesn't read is reported at medium and not counted as automatic. Needs the online dependency lookup; the package's source isn't downloaded.

Files: package.jsonpackage-lock.jsonyarn.lockpnpm-lock.yaml

Locked versions whose OSV malware record describes an honest package with an install-time weakness, such as old fsevents fetching its binary from a storage bucket that could be taken over (CVE-2023-45311). Reported as a weakness, not as malware. Needs the online dependency lookup.

Files: package-lock.jsonnpm-shrinkwrap.jsonyarn.lockpnpm-lock.yamlbun.lock

Names one typo away from popular packages, packages published days ago that almost nobody uses, unpopular packages with install scripts, names that don't exist on npm, and dependencies installed straight from git or a URL.

Files: package.json

A carriage return at the end of a submodule path (CVE-2025-48384), names or paths that reach into .git, ext:: URLs, URLs that start with a dash and shell-command update methods.

Files: .gitmodules

setup.py code that runs at pip install, including first-party modules it imports, custom install commands, hatch custom build hooks, in-tree build backends, and requirements that pull from other indexes, git or URLs.

Files: setup.pyhatch_build.pypyproject.tomlrequirements*.txt

Bundler runs the Gemfile, and every gemspec it loads, as Ruby code. Flagged when one starts a process that downloads code and runs it or reaches malware-like code (backticks, %x, system, exec, spawn, IO.popen, Open3), evaluates Ruby fetched over the network, or require_relative's a file that does. `git ls-files` in a gemspec stays quiet.

Files: Gemfile*.gemspec

Tasks that only run when picked from the task list, flagged when what they run looks like malware or downloads and runs a script.

Files: .vscode/tasks.json.cursor/tasks.json*.code-workspace

npm start, dev, test and build followed through package.json scripts and the require chain of the files they run (npm start runs server.js when there's no start script). The chain is shown in full.

Files: package.jsonscripts.startscripts.dev

The targets a README tells you to type (plain make or its .DEFAULT_GOAL, install, setup, dev, build, test, check and the like) followed through their prerequisites, $(MAKE) -C sub-makes, included .mk files, define blocks and simple variables, plus $(shell …) calls that make runs while reading the file. A download piped to a shell, inline or in a script the recipe runs (a Python or node script that fetches code and runs it counts too), is read-first, and critical from a bare IP or plain http; a recipe that starts malware-like code is critical. uvx, pipx run or npx of a package from a URL, git or under a lookalike name is read-first. Every other target is read too, and reported only when it's critical, since a README can name any of them. $(eval …), $(call …) and target-specific variables aren't expanded.

Files: MakefileGNUmakefile*.mk

The first recipe (what plain `just` runs) and the usual setup, install, dev, build and test recipes, with the recipes they depend on (arguments included), imported files and modules, shebang and [script] recipes read as the language they're written in, plus backticks just evaluates in variables while it loads. Taskfile, mise (inline and file tasks), deno, invoke (tasks.py) and Rake tasks and nox sessions (all of them, or the ones nox.options.sessions names) with the same names (`task setup`, `mise run setup`, `deno task dev`, `invoke setup`, `rake setup`, Rails' `rake db:setup`), with the tasks they call, Taskfile includes and defer commands, Rakefile and rakelib or lib/tasks .rake files, plus Taskfile `sh:` variables and code outside any Rake task or nox session, which run as soon as the tool loads the file. Every other recipe and task is read too, and reported only when it's critical, since a README can name any of them (`just onboard`). Rake reads every .rake file under the Rakefile and the files it imports or loads. None of these tools asks before running a task. A download piped to a shell is "Read first" ("Worth a look" from a GitHub-hosted installer), as is a package fetched from a URL, git or under a lookalike name; from a bare IP or plain http, or reaching malware-like code, it's critical.

Files: justfileTaskfile.ymlmise.tomlmise-tasks/deno.jsontasks.pyRakefilelib/tasks/*.rakenoxfile.py

setup.sh, install.sh, bootstrap.sh and the like at the top of the repo or in scripts/, GitHub-style script/bootstrap and script/setup, and Rails' bin/setup and bin/dev, followed into the scripts they run, with simple variables substituted. A download from a bare IP or over plain http piped to a shell is critical here, because no installer ships that way; anything milder stays a code finding, since real projects pipe their own installers to sh too.

Files: setup.shinstall.shscript/bootstrapbin/setup

Config files that build tools and editor extensions execute as code (next.config.js, vite, tailwind, eslint, prettier, jest and others), flagged when the code in them looks like a payload.

Files: next.config.jstailwind.config.jseslint.config.jsvite.config.ts

Values that look like API keys but decode to a URL, shown decoded and defanged. Critical when the address is a paste or JSON-storage dead drop, a raw IP or a known lure server, or when the code decodes env values and runs what it downloads. Hosted-repo and zip scans don't read .env contents yet.

Files: .env*config.envserver/config/*.env

pytest conftest.py files with payload-like code (a project's own conftest gets no test-folder discount), the first-party modules they import, plugins named by pytest_plugins or by `addopts = -p name` in pytest.ini, tox.ini, setup.cfg or pyproject.toml, sitecustomize.py, usercustomize.py and .pth import lines that Python runs at every startup, Bun preload scripts followed like any script, and a committed node_modules, whose code never gets checked against the registry.

Files: conftest.pypytest.inisitecustomize.py*.pthbunfig.tomlnode_modules/

Core extensions in .mvn/extensions.xml other than well-known ones (Develocity, Takari, Tycho, os-maven-plugin and the like), read-first when the jar ships in the repo or Maven's local repository points inside it; Java agents and extension class paths in .mvn/jvm.config or maven.config that load a jar from the repo; and -XX:OnError commands.

Files: .mvn/extensions.xml.mvn/jvm.config.mvn/maven.config

Hooks in .git/hooks and submodule hooks, which run on commit, checkout and merge. Clones never contain them, so in a zip they're critical; in your own checkout, hook-manager stubs (Husky, lefthook, pre-commit, simple-git-hooks, Git LFS) are routine.

Files: .git/hooks/*.git/modules/*/hooks/*

Husky, lefthook, pre-commit, simple-git-hooks and hooks folders switched on with git config core.hooksPath by an install script or editor task. Routine linting is listed; hooks that reach the network or run malware-like code are flagged.

Files: .husky/*.githooks/*lefthook.yml.pre-commit-config.yamlcore.hooksPath

Heuristics over every source file: eval of downloaded code, obfuscation, base64-hidden URLs, paste and JSON-storage dead drops, blockchain dead drops, credential and wallet sweeps, invisible Unicode payloads, code pushed off-screen and markers from published malware reports. Files no trigger rule starts are reported here: critical only on evidence specific to malware (a known indicator, a C2 shape, code run from a download, a hidden payload, a stealer's exfiltration), high for a sweep of key or wallet stores in a file that also uses the network, otherwise worth a look, because installers and build scripts share the rest.

Files: *.js*.ts*.py*.shand other source files

InvisibleFerret's .n2 and .npl payload files, BeaverTail persistence names, and the Shai-Hulud worm's setup_bun.js loader, bun_environment.js payload, truffleSecrets.json dump and workflow.

Files: .n2/pay.nplsetup_bun.jsbun_environment.jstruffleSecrets.json

For hosted repos, an owner account under 30 days old, mentioned only when other findings are already medium or higher.