vigolium --burp-bridge-url command works against Caido with no CLI changes. Vigolium also accepts --caido-bridge-url as an alias for the same flag — either spelling works on every command and both resolve to the same value.
Findings tab in Caido — filterable findings, request/response evidence, and Copy as Markdown
Download the plugin
The plugin is distributed as a pre-built package from the dedicated repository:Vigolium Caido plugin
Grab the latest
caido-vigolium.zip and browse the source at
github.com/vigolium/caido-vigolium.caido-vigolium.zip directly, or build it from source:
Bridge traffic is labelled by vendor (
source: caido) from Vigolium v0.3.12 onward. Detection is wire-only with no fallback probe, so an older Vigolium reads every bridge record as burp — silently. Rows imported from Caido before that release stay labelled burp and cannot be reclassified after the fact.Install and connect
1
Start the Vigolium server
The plugin needs a running server to talk to. Start one (add Retrieve the API key to paste into the plugin:
--mirror-fs <dir> to also write traffic to disk):2
Load the package into Caido
In Caido, go to Plugins → Install Package → From File and choose the downloaded
caido-vigolium.zip. A Vigolium entry appears in the sidebar.A frontend plugin is enabled per user: check that both Vigolium and Vigolium Backend are ticked under Plugins → Installed, then reload the window — the frontend script is only evaluated on a full page load.3
Point it at your server
Open Vigolium → Settings, enter the Server URL (default
http://127.0.0.1:9002) and API key, then select Test connection to confirm the server is reachable. Both values are stored in the plugin’s own database in Caido Data.4
Send traffic
Use a context-menu action, a keyboard shortcut, or the command palette to dispatch traffic. Findings stream into the Findings tab and the Web UI as they are produced.
Settings tab — server connection, scan options, request statistics, and the shortcut reference
Three dispatch workflows
Right-click a request in Search, Sitemap, Replay, or either message pane — the actions are available directly, without opening a nested menu:
Every action is also a command: open the palette with
⌘K / Ctrl+K and search for Vigolium.
Vigolium preserves headers, cookies, body fields, query parameters, and path segments as scanner input, so a request sent from Replay is scanned exactly as you shaped it.
Under Settings → Scan options you can pin a comma-separated module list and a timeout (30s, 2m); leaving either blank uses the server default. Scan all HTTP records submits every stored record with those options.
Forward proxy traffic automatically
Instead of dispatching requests one at a time, turn on Proxy forwarding (Bridge tab) to send every proxied exchange into Vigolium ingestion. It always starts off when the plugin loads. Combine it with In-scope only so out-of-scope hosts don’t pollute the database, and use the filter rules to allow or deny by file extension, HTTP method, or host — the defaults already drop static assets andOPTIONS/HEAD.
Passive-only ingestion
Pair proxy forwarding with a passive-only server (
vigolium server -S --passive-only) to continuously analyze browsed traffic — secrets, security headers, cookie flags, disclosure — without sending any active requests. See Server & Ingestion.What you get inside Caido
The Vigolium panel is organized into six tabs:
HTTP Records tab — filterable records with Send to Replay, Scan, and Delete on the selected row
Keyboard shortcuts
Rebind them under Caido’s Settings → Shortcuts. The refresh shortcut is contextual — it refreshes whichever record view is currently showing.
The Burp extension’s
Ctrl+Alt+… bindings carry over on Windows and Linux. macOS uses ⌘⌃ instead, because Alt there is the Option dead-key — the OS turns Alt+V into √ before Caido sees it.Sitemap snapshots
Beyond per-request dispatch, the plugin can upload the project’s whole Sitemap to Vigolium in one shot. Open Vigolium → Bridge → Sitemap snapshot and either run a snapshot immediately (⌘⌃S / Ctrl+Alt+S) or enable periodic snapshots (disabled by default; five-minute interval when on). Use In-scope only to exclude out-of-scope traffic.
Snapshots are incremental within the current session and idempotent on the server: requests and available responses upload in bounded chunks, and unchanged records are never duplicated.
Bidirectional live bridge
The live bridge connects Vigolium’s CLI and server to Caido in both directions over a loopback-only listener — query live Caido traffic from Vigolium, or copy Vigolium traffic back into Caido’s Sitemap.
Bridge tab — Sitemap snapshots, the loopback live-bridge listener, proxy forwarding, and filter rules
1
Check the listener in Caido
The bridge is on by default so the bridge flags work as soon as the plugin is installed. Open Vigolium → Bridge to turn it off, change the listener URL (default
http://127.0.0.1:9009), or enable In-scope items only to keep bridge searches within the project’s scope. The plugin refuses any non-loopback bind address.2
Point Vigolium at the listener
Pass the listener URL to any bridge-aware command with the Only when you’d rather not repeat the flag across many commands in the same shell, export the env var once instead:
--caido-bridge-url flag (--burp-bridge-url and -B are the same flag) — this is the recommended way, since each command stays explicit and self-contained:--caido-bridge-url http://127.0.0.1:9009; if you exported VIGOLIUM_BURP_BRIDGE_URL, drop the flag.
Read live Caido traffic
Merge Caido’s traffic into a Vigolium traffic view without persisting anything. Live rows are labelledsource: caido, and the usual filters, sorting, pagination, and JSON output all apply:
GET /api/http-records then returns Caido’s live rows merged with stored ones, and the response carries X-Vigolium-Bridge-Source: caido:
Persist Caido traffic into the database
Two ways in, depending on how much you want:source: caido, so they stay distinguishable after Caido closes. Because the bridge is an import source in its own right, the flag can’t be combined with a path argument or --glob-db in the same import invocation.
Push Vigolium traffic back into Caido
The reverse direction — copy stored records into Caido’s Sitemap so you can work them by hand:--save-to-burp and --save-to-vigolium-db are mutually exclusive — pick a direction per command. (The flag keeps its burp spelling because it names the shared bridge protocol, not the vendor.)
Seed an agentic scan from Caido
Autopilot can pull live traffic across the bridge before it builds its prior-context brief and runs the pre-scan, so the agent starts from the traffic you already browsed instead of rediscovering it:The bridge listener requires no credentials because it only binds to a validated loopback address, rejects unexpected
Host/Origin headers, and uses temporary result references that expire when the listener restarts. Turning the setting off or uninstalling the plugin stops the listener immediately.Caido projects
Caido scopes traffic to the selected project, which Burp has no equivalent of. Two consequences:- A bridge search only ever returns the active project’s traffic. The active project is reported on
/healthand shown in the Bridge tab. - Switching project expires all outstanding search references, exactly as restarting the listener does. The Vigolium client already treats an unknown reference as “search again”.
Send traffic through Caido’s engine
The read/write bridge above moves stored traffic between the two tools. The send bridge goes one step further: it letsreplay, fuzz, and finding issue a request through Caido’s own HTTP stack — so the exact bytes you assembled hit the wire instead of being normalised by Go’s client — and stage the exchange into Replay for manual follow-up.
All of these flags require the bridge URL and are opt-in: without them, each command’s send path is byte-for-byte unchanged. The listener is preflighted once up front, so an unavailable bridge is a single clear error rather than one failure per request.
--send-via-burp, --http-mode, --send-timeout, --to-repeater, --to-organizer, --matches-to-organizer, --push-to-burp. Behaviour is matched wherever Caido allows it; where it cannot be, the plugin picks the closest equivalent rather than pretending:
How traffic is labelled
Which proxy is listening is discovered, not declared: the plugin reportsimplementation: "vigolium-caido-bridge" on every /health, /search, and /inspect reply, and Vigolium maps that through a closed allowlist onto the source column it stamps on each record. So --source caido selects exactly the traffic this plugin served, and the Source column reads caido rather than burp.
Traffic pushed to the Vigolium server (rather than pulled over the bridge) carries X-Vigolium-Source: caido and lands with the same label, so one filter covers both directions.
Two consequences worth knowing:
- Record UUIDs keep the
burp:prefix regardless of vendor. It is a routing token meaning “this record lives behind the bridge, not in the database”, not a provenance label — vendor lives insource. - A Vigolium older than v0.3.12 reads every bridge record as
burp, because detection is wire-only with no fallback probe.
Under the hood
The plugin calls the standard Vigolium API (authenticated withAuthorization: Bearer {API_KEY}):
The loopback bridge listener is a separate, unauthenticated, local-only transport. Its endpoint paths keep the
burp-bridge prefix so no CLI change is required:
For lower-level ingestion details, see Server ingestion; for the Burp Suite equivalent, see Using Vigolium with Burp Suite; for the full plugin reference and source, see github.com/vigolium/caido-vigolium.