IDE Integration

xgrep runs inside your editor, surfacing the same findings as xgrep scan as you type — with quickfixes and project-wide scans. There are three ways to set it up:

• VS Code — install the Mondoo extension and you're done. It starts and manages xgrep for you, with no Language Server to configure. This is the recommended path for VS Code users.
• JetBrains IDEs — install the Mondoo plugin from the JetBrains Marketplace. It finds or downloads xgrep and manages the server for you, and adds a tool window with dependency reachability and bills of materials. This is the recommended path for IntelliJ IDEA, GoLand, PyCharm, WebStorm, Android Studio, and the rest of the family.
• Other editors — Neovim, Vim, Helix, Emacs, Sublime Text, and any other LSP-capable editor connect to xgrep's built-in Language Server (xgrep lsp).

All three paths run the same server under the hood, so the capabilities below apply everywhere.

What you get

• Diagnostics on file open and save, and while typing (a full re-scan of the buffer, debounced at 400 ms and asynchronous — the editor never blocks on a scan). Severity maps CRITICAL/ERROR → Error, WARNING → Warning, INFO → Information; the diagnostic code is the rule ID.
• Quickfix code actions. Findings from rules with fix:/fix-regex: offer an "Apply xgrep fix" action that performs the same replacement as xgrep fix apply.
• Workspace scan. The xgrep.scanWorkspace command scans the whole project in the background and publishes diagnostics for every file with findings — results stream into the problems panel per file as each one finishes, with progress reported over $/progress and a completion notification at the end.
• Fast scan (changed files only). The xgrep.scanChanged command scans only files changed in the git working tree (vs HEAD, plus untracked files) — seconds instead of minutes on large repos. Run xgrep.scanWorkspace once, then xgrep.scanChanged as you work; unchanged files keep their diagnostics.
• CLI parity. The server hides inline-suppressed findings (# nosemgrep), collapses same-rule overlapping matches, and — when running the built-in rules — applies the same production scope as xgrep scan (security findings in test/fixture/example paths are dropped). What you see in the editor is what CI will report.

Resource usage

Because the editor runs xgrep in the background as you work, it is tuned to stay off your machine's critical path rather than scan as fast as possible:

• It uses only a fraction of your cores. Background scans are capped to a desktop-friendly share of the CPU (roughly half your cores, up to a small ceiling) — the whole process, garbage collection included — so the editor never pegs every core.
• It yields to your foreground work. The server lowers its own scheduling priority, so your editor, compiler, and browser always win CPU contention; a scan running behind the scenes should not make the machine feel sluggish.
• Bursts stay bounded. Opening or saving many files at once does not launch one scan per file — concurrent document scans are limited to the same small budget, and a scan made stale by a newer edit is dropped before it does any work. You get current diagnostics without a thundering herd of background scans.

If the machine is dedicated to the scan and you want full speed, set XGREP_SCAN_PRIORITY=high in the environment the editor (or xgrep lsp) is launched from. See Controlling CPU usage for the full picture.

Limitations

Editor scans are per-file, so cross-file taint findings (which need the interfile pass of a full xgrep scan) do not appear in the editor, and cross-rule duplicate collapsing is CLI-only. Command scans skip files larger than 10 MB.

Coding agents

For AI coding agents, prefer the MCP server (xgrep mcp): it exposes scanning plus the code-graph and inspection tools as agent-callable tools, which is far richer than passive diagnostics. The Language Server is the right fit for agents that read editor diagnostics from a session that already aggregates LSP results.