Skip to main content

Documentation Index

Fetch the complete documentation index at: https://quintsecurity.mintlify.app/llms.txt

Use this file to discover all available pages before exploring further.

IDE Extension: Quint in the Editor

Status: Design playbook. Not yet in development. Last updated: 2026-05-03

Why

Quint surfaces risk assessments to a dashboard that developers rarely open. The people who actually need to see “your agent just wrote to /etc/hosts” are staring at Cursor, not a browser tab. Every security tool that won the developer layer — Snyk, GitGuardian, Socket — did it by meeting devs inside the editor. Quint needs to do the same.

Competitive Landscape

Snyk

The gold standard for IDE security UX. Their VS Code extension renders findings inline via DiagnosticCollection (squiggly underlines with severity), a sidebar tree view grouped by issue type, and a webview panel for detailed vulnerability cards. Key UX lessons:
  • Match the IDE’s own design system. Snyk rewrote their extension UI to use VS Code typography, button styles, and hover effects. Cognitive load drops when findings look native.
  • Hierarchy matters. Critical issues get red underlines in the editor. Medium issues live in the Problems panel. Low issues are sidebar-only. Users self-triage by choosing where to look.
  • Never spam notifications. Snyk runs scans on save, not on keystroke. Results update quietly in the diagnostics panel. No toast popups unless the user explicitly triggers a scan.

GitGuardian

Real-time secret detection inline. As soon as a hardcoded credential appears, the line gets a red warning and the status bar shows a count. Their philosophy: make it impossible to miss, but never block the flow. Detection fires on edit; remediation is a click away in a side panel. No modals. The extension works offline with ggshield CLI bundled inside.

Socket.dev

Supply chain risk scores inline on package.json dependencies. Uses CodeLens annotations above import lines showing risk indicators. Settings let teams configure which severity levels surface. The extension talks to Socket’s API but gracefully degrades to cached data when offline. The lesson: let organizations tune the noise level.

Continue.dev

Open-source, 2.8M installs. Architecture worth studying: a TypeScript extension shell talks to a local sidecar process over stdio/HTTP. The sidecar handles model inference and state; the extension handles pure UI. This clean split means the extension stays fast regardless of backend complexity. Their agent mode shows that VS Code’s webview panels can host rich interactive UIs (approval flows, diff views, step-by-step plans) without leaving the editor.

Sourcegraph Cody

Sidebar panel with chat, autocomplete, and context awareness. Key pattern: the extension communicates with a local agent process and/or remote API, with graceful fallback when the remote is unavailable. Cody proves that developers will adopt a persistent sidebar panel if it provides value beyond what inline annotations offer.

VS Code API Surface

The APIs that matter for Quint:
APIUseIntrusiveness
StatusBarItemPersistent badge: agent name, risk score, monitoring stateMinimal
DiagnosticCollectionSquiggly underlines on flagged lines with hover detailLow
CodeLensProviderClickable annotations above flagged tool callsLow
WebviewPanelDivergence card, approval modal, session timelineMedium
TreeViewSidebar: recent events, flagged actions, session listLow
window.showWarningMessageApproval prompt (enforcement mode only)High
window.createOutputChannelDetailed event log for debuggingMinimal
TextEditorDecorationTypeInline gutter icons, background highlightsLow
VS Code’s own UX guidelines are strict: notifications should be a last resort, progress belongs in context (status bar or tree view), and modals require immediate user input that cannot wait. Quint should follow these exactly.

Cursor and JetBrains Compatibility

Cursor is a VS Code fork. As of 2025, most VS Code extensions work in Cursor via OpenVSX or VSIX sideloading. Microsoft has started restricting some proprietary extensions (C/C++, Remote, Pylance) to VS Code only, but open-source and third-party extensions remain compatible. A single VS Code extension codebase will run in Cursor without modification. JetBrains is a fundamentally different platform. Plugins are JVM-based (Kotlin/Java), use Swing/AWT for UI, and integrate via IntelliJ Platform SDK. The API surface is richer in some ways (deep PSI tree access, custom editor inlays) but requires a separate codebase. Snyk and GitGuardian both maintain separate JetBrains plugins. The effort is roughly 2-3x a VS Code extension for equivalent functionality. Recommendation: Ship VS Code first (covers Cursor for free). JetBrains second, only after design-partner demand proves it.

Architecture

+------------------+       WebSocket        +------------------+
|  VS Code / Cursor|  <----- :8081 -------> |  Quint Daemon    |
|  Extension       |                        |  (localhost)     |
|                  |   GET /v1/status        |                  |
|  - status bar    |   GET /v1/events        |  - risk scoring  |
|  - diagnostics   |   POST /v1/approve      |  - ES + NE data  |
|  - webview panel |   WS /v1/stream         |  - MCP intercept |
|  - tree view     |                        |                  |
+------------------+                        +------------------+
The extension is a thin UI layer. All intelligence stays in the daemon. WebSocket stream (ws://localhost:8081/v1/stream): The daemon pushes events in real-time. The extension subscribes on activation and renders updates as they arrive. Events include tool calls, risk assessments, divergence alerts, and session state changes. REST fallback: On activation, the extension fetches current state via GET /v1/status (agent name, session ID, risk score, monitoring mode) and GET /v1/events?since=<timestamp> for recent history. This handles reconnection after IDE restart. Approval endpoint: When enforcement mode is active, POST /v1/approve sends the developer’s accept/deny decision back to the daemon, which unblocks the paused tool call. Port: 8081 (new), not 8080. The daemon’s existing HTTP viewer lives on 8080; the extension API gets its own port to avoid conflicts and allow independent auth.

What Gets Surfaced

Status Bar Badge

Always visible. Single click opens the Quint sidebar panel.
  Quint: Claude Code | risk 23/100 | monitoring
States:
  • monitoring (green dot) — normal observation
  • flagged (yellow dot) — recent high-risk event, number shown
  • enforcement (red dot) — approval required, blocks until resolved
  • disconnected (grey dot) — daemon unreachable

Inline Diagnostics

When a tool call is flagged, the extension places a diagnostic on the relevant line (if the file is open and the path matches). Severity maps to Quint risk tiers:
  • Risk 70+ : DiagnosticSeverity.Error (red underline)
  • Risk 40-69: DiagnosticSeverity.Warning (yellow underline)
  • Risk < 40 : DiagnosticSeverity.Information (blue, only in verbose mode)
Hover text example:
[Quint] Bash tool call flagged
  Action: file_write /etc/hosts
  Risk: 87/100
  Reason: System file modification outside project directory
  Confidence: 0.91
  Session: claude-code-a3f2 | 14:23:07

CodeLens Annotations

Above flagged lines in open files:
[Quint: risk 87 -- file write to /etc/hosts] [View Details] [Approve]
  run("sudo echo '127.0.0.1 evil.com' >> /etc/hosts")
The [View Details] link opens the webview panel. [Approve] only appears in enforcement mode.

Approval Modal (Enforcement Mode)

When enforcement is active and a tool call exceeds the risk threshold, the agent pauses. The extension shows a modal via window.showWarningMessage with actions:
+----------------------------------------------------------+
|  Quint: Approval Required                                |
|                                                          |
|  Claude Code wants to run:                               |
|    bash: sudo echo '127.0.0.1 evil.com' >> /etc/hosts   |
|                                                          |
|  Risk: 87/100                                            |
|  Reason: System file modification outside project dir    |
|                                                          |
|  [ Approve ]  [ Deny ]  [ View Context ]                |
+----------------------------------------------------------+
View Context opens the webview panel with the full event timeline leading up to this action, so the developer can see what the agent was doing and why. Persistent panel in the activity bar (Quint shield icon):
QUINT
  + Active Sessions
    - claude-code-a3f2 (risk: 23, 47 events)
    - cursor-agent-b1c9 (risk: 8, 12 events)
  + Flagged Events (3)
    ! file_write /etc/hosts (risk: 87)
    ! bash: curl attacker.com (risk: 72)
    ! npm install sketchy-pkg (risk: 65)
  + Recent Events
    - file_read src/index.ts (risk: 2)
    - bash: npm test (risk: 1)
    - file_write src/utils.ts (risk: 5)

Divergence Card

One-click from status bar or tree view opens a webview panel showing the last divergent event — where the agent said it would do X but actually did Y. This is Quint’s unique value prop and should be the most polished UI surface.

Auth Flow

Three options in priority order:
  1. Auto-discovery from daemon (preferred). The extension connects to localhost:8081 and the daemon responds if running. No token needed for localhost communication — the daemon already authenticates the machine via its install token. Zero-config for the developer.
  2. Deploy token paste. For cases where the daemon runs on a different host (remote dev, SSH, containers), the extension settings accept a quint.token value. The developer copies it from the dashboard or CLI (quint token show).
  3. OAuth via dashboard. Future. The extension opens a browser flow to app.quintai.dev/auth/ide, receives a callback token, stores it in VS Code’s SecretStorage. Only needed for cloud-only mode without a local daemon.
Auto-discovery covers 95% of the design-partner use case. Ship that first.

Performance Constraints

IDE extensions that lag the editor get uninstalled immediately. Non-negotiable rules:
  • Activation: Use onStartupFinished activation event, not *. Load time must be under 200ms. No synchronous network calls in activate().
  • WebSocket: All daemon communication is async. The extension never blocks the UI thread waiting for a response. If the WebSocket disconnects, the status bar shows grey and the extension operates in degraded mode (no new events, stale data shown).
  • Diagnostics: Batch updates. When the daemon streams 50 events in a burst, the extension debounces diagnostic updates to at most once per 500ms.
  • Webview: Lazy-loaded. The panel HTML/JS is not loaded until the user clicks to open it. Use retainContextWhenHidden: false to free memory when the panel is not visible.
  • Bundle size: Use esbuild to produce a single bundled JS file. Target under 500KB. No heavy dependencies. The extension is a thin client.

Engineering Effort

MilestoneScopeEstimate
MVP (Cursor/VS Code)Status bar badge, WebSocket connection to daemon, sidebar tree view with live events, basic diagnostics on flagged tool calls2 weeks
Enforcement modeApproval modal, POST /v1/approve integration, CodeLens annotations, divergence card webview1.5 weeks
PolishSettings UI (risk threshold, verbose mode), onboarding walkthrough, error states, reconnection logic1 week
Daemon APINew /v1/stream WebSocket endpoint, /v1/status, /v1/events, /v1/approve on port 80811.5 weeks (parallel)
JetBrainsSeparate Kotlin plugin, equivalent feature set4-6 weeks (after VS Code proves out)
Total for VS Code MVP through polish: ~5 weeks with one engineer, or ~3 weeks with the daemon API work parallelized.

Ship Order

  1. Daemon API endpoints — the extension is useless without them. WebSocket stream is the critical path.
  2. VS Code extension MVP — status bar + tree view + diagnostics. Ship to design partners. Get feedback on noise level and risk threshold tuning.
  3. Enforcement mode — approval modal + CodeLens. This is the differentiator. Only enable for orgs that opt in.
  4. JetBrains — only after at least two design partners request it.

Open Questions

  • Risk threshold defaults. What risk score triggers inline diagnostics vs. sidebar-only? Snyk’s lesson: start quiet, let teams crank up sensitivity. Default to 60+ for inline, 40+ for sidebar.
  • Multi-agent. When multiple agents run simultaneously, how does the status bar summarize? Show the highest risk across all sessions, with click-to-expand.
  • Remote development. VS Code Remote SSH and Dev Containers run extensions on the remote host. If the daemon is on the local machine but the extension runs remotely, the localhost:8081 connection breaks. Needs a tunnel or the daemon must also run on the remote.
  • Marketplace publishing. VS Code Marketplace requires a Microsoft publisher account. OpenVSX covers Cursor and VSCodium. Publish to both.