Skip to main content

LSP server + VS Code extension

Vulkro ships a Language Server Protocol server, exposed as the vulkro lsp subcommand of the main binary, and a thin VS Code extension that consumes it. The same .vsix loads in Cursor and Windsurf (both VS Code forks).

The LSP surfaces Vulkro findings inside your editor as diagnostics, with hover-to-explain and a read-only suppress code action.

Read-only by design​

The editor integration never rewrites your code. The only edit it can make is inserting a // vulkro:disable next-line <RULE> suppression comment, and only when you ask for it. There are no logic-rewriting "auto-fixes": no CORS edits, no debug-flag flips, no secret-to-env rewrites. Detection is the product; the editor is a read-only lens on it.

Install​

The extension spawns the vulkro binary you already have, so install the scanner first (see the install guide). The extension itself is distributed as a .vsix; build it from editor-extensions/vscode with npm install && npm run package, then install the .vsix through your editor.

If the binary cannot be found when the extension starts, it offers an Install action (also the Vulkro: Install or update the scanner binary command) that downloads the right release for your platform, verifies its .sha256, and installs it into ~/.vulkro/bin. That download runs only when you trigger it and respects VULKRO_OFFLINE=1.

What you get​

  • Diagnostics on save. Open any Python, JavaScript, TypeScript, JSX/TSX, Go, Ruby, Java, C#, or PHP file inside a project with a .git, package.json, pyproject.toml, go.mod, or vulkro.toml root marker. Save the file. Vulkro re-scans the project root and surfaces findings under the cursor.
  • Salesforce projects additionally start a second vulkro-sf lsp server for Apex, Aura, Visualforce, Flow, and metadata. See the Salesforce extension page for the SFDX specifics.
  • Hover to explain. Hovering a diagnostic surfaces the rule id, severity, message, and remediation in a Markdown popup.
  • Suppress + Explain code actions. The lightbulb on any Vulkro diagnostic offers Suppress (insert the vulkro:disable comment) and Explain (render the rule's long-form explainer).
  • Findings panel + status bar. A dedicated Vulkro view in the activity bar groups findings by severity; a status bar item shows the live count.
  • Severity filter. vulkro.severityThreshold drops findings below the chosen level before they reach the editor.

Settings​

SettingDefaultPurpose
vulkro.pathvulkroPath to the vulkro binary, or the bare name if it is on PATH. The extension spawns <path> lsp.
vulkro.severityThresholdmediumMinimum severity to surface (critical, high, medium, low, info).
vulkro.rulePackdefaultAudit-profile bias passed to the server.
vulkro.lsp.debounceMs300Debounce window (ms) for re-scans, clamped to [50, 5000]. Passed as VULKRO_LSP_DEBOUNCE_MS.
vulkro.trace.serveroffTrace LSP traffic in the Vulkro output channel.

Because the server maps Critical and High to the same editor severity (Error), the critical and high thresholds behave identically in the editor.

How the LSP talks to the scanner​

vulkro lsp runs the scan in-process: no subprocess, no JSON-over-pipe. It gets the same detection results as the CLI: the full extractor set, the auth model, reachability gating, taint analysis, and cross-service correlation. It inherits the CLI's high-confidence default, so the findings the editor surfaces are the same ones CI would.

Performance​

Today the LSP re-scans the whole project root on every save. For a 5k file repo that is typically 1 to 3 seconds; for a 50k file monorepo it can be 10 to 30 seconds. Incremental scanning makes subsequent saves much cheaper; the first save after opening the editor is the expensive one.

For a faster loop, run vulkro scan . --watch (see CLI: scan) in a side terminal.

Suppressing network egress from inside the editor​

To suppress all network egress from the binary the editor spawns, set:

// settings.json
"terminal.integrated.env.osx": {
  "VULKRO_NO_UPDATE_CHECK": "1",
  "VULKRO_OFFLINE": "1"
}

(Adapt osx to linux / windows as needed.)

What this isn't (yet)​

  • No standalone JetBrains plugin. The server works with any LSP-aware editor in principle (Neovim's nvim-lspconfig, Helix, Zed). VS Code (and its forks) is the only one with a packaged extension today.
  • No logic-rewriting quick-fixes. Suppression is the only edit, by design.
  • No real-time as-you-type diagnostics. Triggered on save, not on every keystroke (a didChange reads from disk, not the unsaved buffer).
Last updated on