Roo Code MCP security workflow

Set up LyraShield MCP in Roo Code by authenticating with the CLI, running the roo-code installer to write .roo/mcp.json, verifying the connection, running an inline scan on the changed scope, adding a GitHub Action diff gate that emits SARIF and adding an agent rules snippet. Roo Code requires the hyphenated streamable-http transport type, so the installer writes the correct value. Per the vibe coding security guide, treat scan output as evidence and keep outcomes distinct.

1. Install prerequisites and authenticate

Roo Code is a VS Code extension that reads MCP configuration from .roo/mcp.json at the project level (overriding the global mcp_settings.json) using the mcpServers root key. Before wiring LyraShield, install Node so npx is available, then authenticate once with npx -y lyrashield@0.2.14 login --oauth. The CLI writes credentials to ~/.lyrashield/credentials.json with restrictive permissions and commits nothing. Confirm the official Roo Code MCP documentation is the version you target and that VS Code is open to your project workspace.

A clean prerequisite check avoids the most common Roo Code setup failures. The project file overrides the global one, so a stale global entry can shadow your project edit if the names collide; keep server names unique across both. Note now that Roo Code requires the hyphenated streamable-http type for remote servers, so a copy pasted http value from another tool’s docs will silently fail to connect. Keep your auth token in the credentials file only and never paste it into a committed config or a pull request description.

The .roo/mcp.json file is the project level source of truth for MCP servers. Because it overrides the global file, team server definitions should live here so contributors inherit the same security tooling on clone.

2. Add the LyraShield MCP server with the CLI

Follow the current roo-code integration guide and manually merge the server entry, preserving existing settings. Authenticate local stdio separately with npx -y lyrashield@0.2.14 login --oauth and use @lyrashield/mcp@0.2.12. Use pinned CLI commands for documented config or skill installs; marketplace plugins remain separately gated. Restart the client, confirm discovery, then call lyrashield_list_workspaces for authenticated read-only access. CLI doctor does not establish client authentication or scan completion.

If you run the installer inside a monorepo, run it from the directory that holds your .roo/ folder so the entry lands in the right project scope. The installer checks that your Node version supports npx streaming fetch, which streamable-http depends on.

3. Configure the MCP server manually when needed

If you must edit by hand, add an entry under mcpServers in .roo/mcp.json. The critical detail is the transport type: Roo Code requires streamable-http with a hyphen. The bare http value and the camelCase streamableHttp value both fail to connect, confirmed by the GitHub MCP server install guide.

{
  "mcpServers": {
    "lyrashield": {
      "type": "streamable-http",
      "url": "https://app.lyrashieldai.com/api/mcp",
      "headers": {
        "Authorization": "Bearer lsk_REPLACE_WITH_YOUR_TOKEN"
      },
      "alwaysAllow": [],
      "disabled": false
    }
  }
}

Keep alwaysAllow minimal. Never commit a real token; keep the literal in the user level file or environment and commit only a redacted structure. The CWE-798 hard coded credentials pattern is the exact risk. If you prefer a local stdio server instead of the remote endpoint, swap the entry for a stdio server with command: "npx", args: ["-y", "@lyrashield/mcp@0.2.12", "stdio"] and an env map that injects your token, then leave disabled: false. Choose the transport in the current client guide; the published installer does not write either form. Local stdio reads the user-only credential store after separate CLI OAuth login. Hosted API keys provide read-only access; authenticated hosted mutations require a valid browser-confirmed delegation. Whichever you choose, reload the client, inspect discovery and confirm an authenticated read-only call, since a streamable-http typo is the most common failure and produces no error.

The alwaysAllow array lists tool names the agent may call without an approval prompt. Leaving it empty means every scan invocation asks for confirmation, which is safer for shared workstations. If you add LyraShield scan tools to alwaysAllow, name the exact tool, not a wildcard, so a future server update cannot widen what runs unattended.

4. Verify the connection and run an inline check

After config, reload the VS Code window so Roo Code picks up the file, then run npx -y lyrashield@0.2.14 doctor to confirm the server reports connected. In the Roo Code pane, ask the agent to run a LyraShield scan against the current target. The agent targets the release scope and returns findings in the shipped DETECTED, VALIDATED and INCONCLUSIVE states. The separate VERIFIED state is reserved for a future capability and is not produced by current scans. Keep those evidence states distinct as described in the vibe coding security guide. Scan the changed scope, not the whole repo, to keep feedback fast.

If the server shows as loaded but no scan tools appear, the usual cause is a streamable-http typo (a bare http or camelCase streamableHttp), a mixed stdio and url field set or a disabled: true flag. The doctor command and the Roo Code MCP pane surface each. When you read scan results, keep detection and retest separate: a detected candidate is a signal worth review and a clean deterministic retest is the only state that shows the condition is gone. Keep the output in your release record so a reviewer can trace each finding to its evidence.

A typical evidence example reads “detected: hardcoded API key in src/config.ts line 42; retest-confirmed: the same check no longer flags it after a refactor.” Each clause is a separate record. An inconclusive outcome, such as a dependency advisory with no fixed version, gets its own line so it is not lost between detected and retest rows.

5. Add a GitHub Action diff gate in CI

To block regressions in pull requests, add the LyraShield GitHub Action in diff aware mode. It scans only changed files and emits SARIF output for GitHub code scanning. See the integrations documentation for the exact action ref and inputs.

name: lyrashield-diff-scan
on:
  pull_request:
    branches: [main]
permissions:
  contents: read
  security-events: write
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - name: LyraShield diff scan
        uses: ecryptoguru/lyrashield-ai@v2
        with:
          fail_on_severity: HIGH

The GitHub code scanning SARIF support docs describe how SARIF feeds alerts into your pull request view. The runner-local Action needs no LyraShield token. A diff aware gate keeps CI fast and focuses review on what changed, but it is not a substitute for a full recorded release scan. If the Action flags a dependency advisory, verify it against the resolved version before blocking a merge.

Because the diff scan only reads changed files, it stays fast even on large repos. The Action manages the required checkout depth and SARIF upload itself.

6. Add an agent rules snippet

Tell the agent how to use LyraShield so it does not improvise. Add a short rule to your Roo Code custom instructions or project rules file:

Before proposing release, run a LyraShield scan on the changed scope.
Treat scan output as evidence, not proof.
Propose fixes only; do not auto apply. Retest after any fix.
Keep detected candidates, deterministic retest validations and inconclusive results distinct. Do not describe a LyraShield scan result as `VERIFIED`; current scans do not produce that reserved state.

A short rule prevents the agent from treating a clean scan as a release verdict or from applying a patch without review. Pair the rule with a repository convention that scan receipts land in your release record, so the evidence loop has a durable home. If your team shares the .roo/mcp.json across workspaces, keep the LyraShield lines in a project rules file that travels with the repo rather than only in your global settings.

The rule works because it fixes agent behavior before any scan runs. Without it, an agent may summarize a clean scan as “safe to ship” or apply a patch the moment it appears. With it, the agent produces evidence, waits for review and retests only after you approve.

Step	Command or file	Purpose
Authenticate	npx -y lyrashield@0.2.14 login --oauth	Write credentials to ~/.lyrashield
Add server	Current client guide	Manually merge the documented entry
Verify	npx -y lyrashield@0.2.14 doctor	Confirm the server connects
Diff gate	GitHub Action workflow	Block regressions in pull requests

Why pair Roo Code with LyraShield

Roo Code gives you a capable VS Code agent with a flexible MCP model and that flexibility is where release risk hides: a streamable-http typo that silently disconnects a security server, an over broad alwaysAllow array or a committed token in a shared config. LyraShield pairs with that loop by targeting the release, reviewing the real config, collecting independent evidence, proposing fixes that require review, retesting and reporting. It does not auto fix. Approval gated fix proposals stay proposals until a server generated patch is bound to an exact approval.

LyraShield is live with open registration. Create an account to run a scan and use the AI app security checklist to structure your pre launch review. For a parallel setup, see the Codex security workflow.