Open a project in VS Code with the Snyk extension installed, and something happens before you've typed a single line: Snyk Code silently kicks off a scan of the workspace. Save a file five minutes later, and it may scan again — or it may not, depending on a setting most developers never look at. Click the Snyk icon in the sidebar, and you get a third path entirely: an on-demand scan you control directly.
These three triggers — open, save, and manual — are the backbone of how Snyk Code operates as an in-IDE static analysis tool across its VS Code, JetBrains, Visual Studio, and Eclipse plugins. Understanding exactly when each one fires matters for two practical reasons: it explains why scan results sometimes feel stale or duplicated, and it tells you how to tune the plugin so it fits your workflow instead of fighting it. Here's how the triggers actually work, based on Snyk's own documented plugin behavior.
What triggers a Snyk Code scan the moment you open a project?
Opening or reloading a workspace is the first automatic trigger. When you open a folder in VS Code, or open/re-index a project in a JetBrains IDE (IntelliJ IDEA, PyCharm, WebStorm, GoLand, and others), the Snyk plugin initiates a full scan of the codebase as soon as it has authenticated and identified the relevant source files. This is the plugin's way of giving you a baseline: rather than waiting for you to touch a file, it establishes what issues already exist in the project the moment you start working in it.
This initial scan runs through the same underlying analysis engine used for later scans, but it necessarily has the most work to do since nothing has been cached yet. Snyk's IDE integrations are built on a shared Language Server Protocol (LSP) component, published by Snyk as snyk-ls, which is what lets VS Code, JetBrains, Visual Studio, and Eclipse all expose consistent scanning behavior from one underlying engine rather than four separate implementations. That shared architecture is also why the open, save, and manual triggers behave the same way regardless of which editor you use — the differences you notice are mostly in the UI surface (a Problems panel versus a dedicated tool window), not the scanning logic itself.
Does saving a file automatically kick off a new Snyk Code scan?
Yes, by default — but it's a setting you can turn off. Snyk's IDE plugins include an automatic scanning option (labeled as "automatic scan" or "scan on save" depending on the plugin) that is enabled out of the box. With it on, every time you save a file, Snyk Code re-analyzes the workspace and updates the findings shown inline and in the results panel. This is what gives Snyk Code its "shift left" pitch: a SQL injection pattern or hardcoded credential you just typed can surface as a warning within moments of hitting save, before the code ever reaches a pull request.
The practical effect of save-triggered scanning is that feedback loops shrink to the length of your local edit-save cycle rather than the length of a CI pipeline run. That's valuable for catching an issue while the context is still in your head. It's also why teams with large monorepos sometimes report scans feeling intrusive on every save — which is precisely the behavior the automatic scanning toggle exists to control.
How do you manually trigger a Snyk Code scan, and when should you?
You trigger a manual scan through the plugin's command interface — the Command Palette entry ("Snyk: Scan") in VS Code, or the scan button in the Snyk tool window in JetBrains IDEs — and it runs independently of the open or save triggers. Manual scanning exists for the cases where automatic scanning isn't practical or isn't enabled: after pulling a large set of changes from a teammate's branch, after switching branches entirely, after editing files outside the IDE (say, via a script or a merge tool), or simply when a developer wants to re-check the project state without making an edit first.
Manual triggers are also the fallback when automatic scanning has been deliberately disabled. Some organizations turn off scan-on-save for performance reasons on large codebases and instead rely on developers running a scan before opening a pull request, or on a scheduled/manual check at natural workflow checkpoints. In either case, the manual trigger uses the same engine and produces the same finding format as the automatic ones — it's a difference in when the analysis runs, not what the analysis does.
Can developers turn off automatic scan triggers, and what happens if they do?
Yes — both the open-triggered and save-triggered scans can be disabled through the plugin's settings, and doing so shifts all scanning responsibility to the manual trigger. In VS Code this is exposed as an automatic scanning setting in the Snyk extension configuration; JetBrains plugins expose an equivalent toggle in the Snyk tool window preferences. When automatic scanning is off, the plugin does not analyze code until a developer explicitly runs a scan or, in some setups, until a CLI invocation (snyk code test) is run from the integrated terminal.
Turning off automatic triggers is a real tradeoff, not just a performance switch. It reduces IDE overhead on very large repositories where a full re-scan on every save is noticeably slow, but it also means a vulnerable pattern can sit unflagged in a file for as long as the developer goes without manually scanning. Teams that disable automatic triggers typically compensate with a mandatory scan step elsewhere — a pre-commit hook, a required CI job, or a pull-request gate — so the local editor is a convenience layer rather than the only checkpoint.
Why might IDE scan results look different from what shows up in CI/CD or the Snyk web console?
Because the IDE, CLI, and CI/CD integrations can run against different code states and at different points in time, so a discrepancy usually reflects a timing gap rather than an inconsistency in the scanner itself. An IDE scan reflects the file contents on disk at the moment it runs, including any unsaved or uncommitted local edits (once saved). A CI pipeline scan, by contrast, reflects whatever was actually pushed and checked out for that build — which may be a commit or two behind what's currently open in your editor, or may include changes from other contributors merged since you last pulled.
Version and configuration drift compounds this. If a developer's local IDE plugin is on an older release than the version of Snyk Code running in CI, or if project-level ignore rules and severity thresholds are configured differently between the two contexts, the same underlying finding can appear, disappear, or be prioritized differently depending on where you're looking. This is a common source of confusion in security reviews — a finding closed out in the web console can reappear locally simply because the developer hasn't pulled the latest ignore-list changes yet.
How Safeguard Helps
Understanding scanner triggers matters because IDE-level SAST is only one checkpoint in a much longer software supply chain, and the value of a fast local finding depends on whether it's actually acted on consistently downstream. Safeguard's role isn't to replace what tools like Snyk Code do at the editor level — it's to make sure the signal generated at every stage of the pipeline, from IDE to build to registry to production, is tied together into a coherent, auditable picture instead of living in disconnected panels and dashboards.
In practice, that means Safeguard correlates findings across the stages where triggers like open, save, and manual scans leave gaps: a developer who disables automatic scanning, a branch that skips a manual check before merge, or a CI run pinned to an older scanner version. Safeguard's policy engine can enforce that a scan actually ran and passed before code progresses — regardless of whether a given developer's local plugin settings would have caught the issue — and its provenance and SBOM tooling give security teams a record of what was scanned, when, and against which commit, closing the exact kind of timing and configuration drift described above. For teams building a software supply chain security program, that continuity across local, CI, and production checkpoints is often the difference between a tool that catches issues and a program that can prove it consistently does.