Oh My Pi MCP security workflow

Set up LyraShield MCP in Oh My Pi by authenticating with the CLI, manually merging the documented mcpServers entry into the agent subdirectory, 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. Oh My Pi supports stdio, http and sse transports, with manual setup through the current guide. Per the vibe coding security guide, treat scan output as evidence, not proof.

1. Install prerequisites and authenticate

Oh My Pi (omp.sh) reads OMP native MCP configuration from .omp/mcp.json at the project level and ~/.omp/agent/mcp.json at the user level, with profile aware paths under ~/.omp/profiles/<name>/agent/mcp.json. 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 Oh My Pi MCP configuration guide is the version you target and that the path correction pull request is reflected in your install.

A clean prerequisite check avoids the most common OMP setup failures. The user config path is ~/.omp/agent/mcp.json, not the older ~/.omp/mcp.json; users who follow the stale path see no servers load. Note now that OMP auto discovers servers from other tools, so a server you configured for Claude Code or Cursor can appear in your OMP session without an explicit entry. Keep your auth token in the credentials file only and never paste it into a committed config or an issue.

2. Add the LyraShield MCP server with the CLI

Follow the current oh-my-pi 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.

3. Configure the MCP server manually when needed

If you must edit by hand, add an entry under mcpServers in .omp/mcp.json. The critical detail is the path: use the agent subdirectory for user level config, because the older ~/.omp/mcp.json path is not read by the runtime. Oh My Pi supports stdio (the default when type is omitted), http for remote servers and sse for legacy. For the remote LyraShield endpoint, use the http type:

{
  "mcpServers": {
    "lyrashield": {
      "type": "http",
      "url": "https://app.lyrashieldai.com/api/mcp",
      "headers": {
        "Authorization": "Bearer lsk_REPLACE_WITH_YOUR_TOKEN"
      },
      "enabled": true
    }
  }
}

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 use /mcp add inside an Oh My Pi session, it writes this structure atomically with restrictive permissions. 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; the type field is optional and defaults to stdio. 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, confirm tool discovery inside the client and make an authenticated read-only call, since a config path mistake is the most common failure and produces no error.

4. Verify the connection and run an inline check

After config, run npx -y lyrashield@0.2.14 doctor to confirm the server reports connected. Inside an Oh My Pi session, 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 config path mistake (the older ~/.omp/mcp.json instead of the agent subdirectory), a server name collision shadowed by a higher priority discovery source or a disabledServers entry that suppresses it. The doctor command surfaces the first; review your discovery sources and denylist for the others. 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.

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. It derives the changed files from the pull-request range and uploads SARIF; use a separate recorded scan for full release evidence. If the Action flags a dependency advisory, verify it against the resolved version before blocking a merge.

Keep the distinction visible in pull-request templates: the local Action receipt covers the changed diff, while a hosted scan records its own target revision, coverage bounds, finding identities and retest evidence.

6. Add an agent rules snippet

Tell the agent how to use LyraShield so it does not improvise. Add a short rule to your Oh My Pi rules file or agent configuration:

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 uses named OMP profiles, keep the LyraShield rule in a profile independent location like the project .omp directory so it applies under every profile rather than only the one where you authored it.

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 server 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 Oh My Pi with LyraShield

Oh My Pi gives you a flexible coding agent with broad MCP discovery and that flexibility is where release risk hides: a stale config path that silently loads nothing, a discovered server that widens what the agent can touch 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 Windsurf security workflow.