code-server

VS Code in a browser, extension host on the server. Full support, despite the browser.

code-server serves VS Code over HTTP with the extension host running on the server. The interface is a browser tab, but the extension is a Node process sitting next to your files, so everything works, including scanning.

This surprises people. “In the browser” is not the same as “in the browser sandbox”: what matters is where the extension host runs, and here it runs on the server.

Install

code-server uses Open VSX. From the Extensions view, or on the host:

code-server --install-extension vulnetix.vulnetix

To bake it into an image:

RUN code-server --install-extension vulnetix.vulnetix \
 && curl -fsSL https://cli.vulnetix.com/install.sh | sh

Installing the CLI at build time means the first scan starts immediately instead of downloading ~40 MB on first use.

Multi-user hosts

Each user’s extension host is a separate process with its own storage, so each downloads its own CLI copy and holds its own credential. On a shared host that is duplicated disk. Install the CLI once system-wide and point everyone at it:

// in the machine-scope settings
{ "vulnetix.cli.path": "/usr/local/bin/vulnetix" }

vulnetix.cli.path is machine-scoped by design, so a cloned repository’s .vscode/settings.json cannot redirect it at a binary of its choosing.

Resource use

The scanning engine holds its compiled rule set in memory for speed. On a host running many concurrent users, cap it:

{
  "vulnetix.lsp.memoryLimitMb": 1024,
  "vulnetix.lsp.idleShutdownMinutes": 30
}

Idle shutdown releases the engine when a user stops working, and it restarts transparently on the next scan.

Sign-in

Sign-in opens a browser tab to approve a short code. Since your browser is already the client, this works with no port forwarding or tunnelling. If your code-server sits behind an SSO proxy, the approval happens on vulnetix.com and is unaffected.