Match your editor to CI

So the pull request never tells you something the editor did not.

The failure mode this avoids: your editor says clean, CI says blocked, and you learn to ignore your editor.

Same engine, already

Vulnetix runs the same binary in both places. What differs is configuration, so parity is a configuration problem.

If you are signed in, it is already done

An organisation quality gate applies in both. The editor retrieves the policy and enforces the same thresholds CI does, and where an organisation value and a local setting disagree, the organisation wins.

That is the whole feature. Stop here.

If you are not

Mirror your CI flags in workspace settings, committed so the team shares them:

// .vscode/settings.json
{
  "vulnetix.qualityGate.severity": "high",
  "vulnetix.qualityGate.exploits": "active",
  "vulnetix.sca.maxMajorBump": 1,
  "vulnetix.license.allow": "MIT,Apache-2.0,BSD-2-Clause,BSD-3-Clause,ISC"
}

against a workflow like:

- uses: Vulnetix/cli@v3
  with:
    task: scan
    org-id: ${{ secrets.VULNETIX_ORG_ID }}
    api-key: ${{ secrets.VULNETIX_API_KEY }}
  env:
    VULNETIX_SEVERITY: high
    VULNETIX_EXPLOITS: active

What will still differ, legitimately

Secrets in git history. CI walks it; the editor does not, because it takes minutes. A secret committed and later removed shows up in CI and not locally. That is correct behaviour, not drift.

Full-repository scope. The editor checks what you touch. CI checks everything, including files nobody has opened.

Reachability and enrichment. Some analysis is available to a signed-in CI run and not to an anonymous local one.

Where these produce a CI finding you did not see locally, run Vulnetix: Scan Workspace to reproduce it on demand.

Pre-commit

Editor checks are advisory. If you want a hard stop before a commit, add a hook that runs the CLI directly. That is a CLI concern rather than an extension one; see the CLI documentation.