Continue.dev is an open-source AI coding assistant that runs inside VS Code and JetBrains IDEs. It is MCP-native: tools, context providers, and integrations get loaded from MCP servers declared in the Continue config. Pipelock wraps each of those servers so every tool call and response runs through its MCP proxy.
Why Continue.dev needs an agent firewall
Continue sessions frequently involve:
| Workflow | What Continue accesses | What could go wrong |
|---|---|---|
| Multi-file edits | Source code, secrets in history | Credentials leaked through tool arguments |
| Context providers | Repository search, docs, URLs | Prompt injection in fetched content |
| MCP tool execution | Filesystem, databases, APIs | Tool poisoning, rug-pull updates, chain attacks |
| Conversation history | Past plans, tool outputs | An injected instruction surviving across resume |
Pipelock sits inline on each MCP server. It scans tools/call arguments outbound for DLP, scans tool responses inbound for prompt injection, scans tool definitions for poisoned descriptions, and emits signed action receipts so an operator can prove what happened.
Install pipelock
# Homebrew (macOS / Linux)
brew install luckyPipewrench/tap/pipelock
# Go
go install github.com/luckyPipewrench/pipelock/cmd/pipelock@latest
Wrap each MCP server in your Continue config
Continue supports MCP servers in a top-level mcpServers block and in standalone files under .continue/mcpServers/. Continue’s current docs show standalone YAML files with name, version, schema, and a mcpServers list; if your setup uses the global config.yaml, edit the same mcpServers list there.
For stdio servers, keep Continue’s transport as stdio and replace the original command with pipelock mcp proxy. Put the original command and arguments after --. The pattern is identical to the install subcommands shipped for other IDEs.
A command-based MCP server changes from:
name: Local MCP Servers
version: 0.0.1
schema: v1
mcpServers:
- name: filesystem
type: stdio
command: npx
args:
- "-y"
- "@modelcontextprotocol/server-filesystem"
- "/tmp"
to:
name: Local MCP Servers
version: 0.0.1
schema: v1
mcpServers:
- name: filesystem
type: stdio
command: pipelock
args:
- mcp
- proxy
- --config
- /home/you/.config/pipelock/local.yaml
- --
- npx
- "-y"
- "@modelcontextprotocol/server-filesystem"
- "/tmp"
A remote MCP server changes from Continue’s direct remote transport:
name: Remote MCP Servers
version: 0.0.1
schema: v1
mcpServers:
- name: remote-example
type: streamable-http
url: https://api.example.com/mcp
to a local stdio wrapper that points Pipelock at the upstream URL:
name: Remote MCP Servers
version: 0.0.1
schema: v1
mcpServers:
- name: remote-example
type: stdio
command: pipelock
args:
- mcp
- proxy
- --config
- /home/you/.config/pipelock/local.yaml
- --upstream
- https://api.example.com/mcp
If your workspace already has JSON MCP config from Claude Desktop, Cursor, or Cline, Continue can load it from .continue/mcpServers/. Wrap those servers the same way, but preserve the JSON file’s existing object shape. Continue’s own docs are the authoritative reference for the exact schema of each MCP server block.
Restart Continue
Quit and reopen your IDE so Continue reloads its configuration and spawns each MCP server through pipelock instead of the original command.
What gets scanned
| Direction | What | Scanning |
|---|---|---|
| Continue → MCP server | Tool call arguments | DLP, input injection patterns, tool-policy rules |
| MCP server → Continue | Tool results, error messages | Response injection with 6-pass normalization |
| Tool definitions | tools/list responses | Poisoned descriptions, schema injection, rug-pull drift |
| Tool sequences | Multi-call patterns | Chain detection |
| Session inventory | First-seen tool set | Inventory pinning so a malicious mid-session server cannot add new tools silently |
When the redaction section is enabled in the pipelock config, matched secrets inside tools/call arguments are rewritten in place with typed placeholders before they reach the MCP server.
Forward proxy for HTTP egress
For HTTP that Continue’s agent makes outside the MCP surface (curl-style tool calls, REST clients), run pipelock as a forward proxy and point the IDE shell at it:
pipelock run --config ~/.config/pipelock/pipelock.yaml &
export HTTPS_PROXY=http://127.0.0.1:8888
export HTTP_PROXY=http://127.0.0.1:8888
export NO_PROXY=127.0.0.1,localhost
Combined with MCP wrapping, this gives full coverage of both egress surfaces a Continue session uses.
Choosing a config
| Preset | Action | Best for |
|---|---|---|
balanced.yaml | warn | Getting started, tuning phase |
claude-code.yaml | block | Unattended Continue sessions on regulated codebases |
strict.yaml | block | High-security repos, third-party plugin work |
hostile-model.yaml | block | Running an uncensored or jailbroken model |
Start with balanced.yaml to see what gets flagged. Switch to claude-code.yaml or strict.yaml once you have verified no false positives in your workflow.
Verify
pipelock discover reports MCP servers across every IDE it knows about, including Continue.dev. Once the wrap is in place, every server should show as protected.
Action receipts
For Continue workflows that touch production source code, enable the flight recorder so each tool call produces a verifiable receipt:
flight_recorder:
enabled: true
dir: /var/lib/pipelock/continue-evidence
sign_checkpoints: true
redact: true
Receipts verify byte-for-byte against the published Python verifier. The format is open and the verifier is independent of the Pipelock binary; see Action Receipt Spec.
Limitations
- Manual wrap. Until
pipelock continue installships, the wrap is a hand edit of Continue’s config. Re-running it after adding a new MCP server is a manual step. - Tool response redaction. Request-side only in v1: arguments are rewritten before forwarding, but tool responses are not. Use prompt injection and tool poisoning detection on the response path for response-side coverage.
- IDE restart required after editing the Continue config.
See also: Claude Code · Cursor · VS Code · Full documentation