• hol-guard start Shows the next step for the harnesses Guard found.
• hol-guard init Runs first-run onboarding as approval checkpoints: local dashboard, harness discovery and install, optional Guard Cloud connect, and desktop notification setup.
• hol-guard bootstrap Detects the best local harness, starts the approval center, and installs Guard in front of it.
• hol-guard hermes bootstrap Installs the Guard-managed Hermes overlay bundle directly.
• hol-guard status Shows what Guard is watching now.
• hol-guard install <harness> Creates the launcher shim for that harness.
• hol-guard uninstall --self Removes Guard-managed harness wiring, package shims, local Guard state, and uninstalls the current hol-guard package.
• hol-guard update Updates the installed hol-guard package in the current environment.
• hol-guard run <harness> --dry-run Records the current state once before you trust it.
• hol-guard run <harness> Reviews changes before launch and hands blocked sessions to the approval center when needed.
• hol-guard approvals Lists pending approvals or resolves them from the terminal.
• hol-guard receipts Shows local approval and block history.

• claude-code Guard prefers Claude hooks first, then the local approval center when the shell cannot prompt.
• copilot Guard can wrap the copilot CLI, detect ~/.copilot/config.json, ~/.copilot/mcp-config.json, workspace .vscode/mcp.json, and install Guard-managed Copilot hook wiring for documented preToolUse and postToolUse events. Guard does not treat a VS Code Copilot inline permission sheet by itself as proof of Guard interception; current proof should come from Guard hook responses, Guard receipts, or an MCP client that explicitly answers Guard elicitation.
• codex Guard asks inline in the same Codex chat when the interactive CLI or Codex App can answer MCP elicitations, and falls back to the local approval center only for codex exec or any other nonresponsive session. When Guard has the right Codex thread binding, approving or blocking in the browser resumes the same Codex thread with HOL Guard-branded continuation copy. Live app-server sessions continue in place, and headless codex exec sessions resume through codex exec resume with the exact blocked command context. If the session cannot be identified, Guard says so plainly and tells you the manual next step instead of pretending it resumed.
• cursor Guard respects Cursor’s native tool approval and focuses on artifact trust before launch.
• opencode Guard authors package-level policy while OpenCode keeps native once, always, or reject prompts for managed MCP tools.
• kimi Guard installs managed PreToolUse and UserPromptSubmit hooks in ~/.kimi-code/config.toml, blocks with exit code 2 and a JSON permissionDecision: "deny" response, and fails open on hook crash or timeout.
• grok Guard installs a catch-all Grok PreToolUse hook plus observe-only prompt and subagent hooks under ~/.grok/hooks/, writes permission deny rules and backup hooks in ~/.grok/managed_config.toml, blocks tool calls with exit code 2 and a Grok-native {"decision":"deny"} response, never reads ~/.grok/auth, and launches only a trusted absolute Grok executable. Custom install roots can be selected once with hol-guard run grok --grok-executable /absolute/path/to/grok. After upgrading an existing Grok install, run hol-guard apps repair grok so the catch-all hook replaces the older per-tool matcher list.
• pi Guard scans ~/.pi/agent/ and project .pi/ packages, extensions, skills, prompts, and themes; installs a managed Pi extension that reviews input and tool_call events inline; and blocks with a Pi-native {"decision":"deny"} response when Guard policy says no.
• zcode Guard detects ~/.zcode/cli/config.json, configured MCP servers, enabled plugins, the plugin cache, and plugin manifests; installs managed PreToolUse and UserPromptSubmit hooks in the config hooks section without touching user mcp or plugins; and blocks with exit code 2 and a permissionDecision: "deny" response.
• hermes Guard installs a managed Hermes overlay bundle, routes MCP servers through Guard proxies, and prefers native-or-center delivery for blocked requests.
• gemini Guard scans extensions and falls back to the local approval center for blocked changes.

How Trust Scoring Works

The scanner now emits explicit trust provenance alongside the quality grade:

• bundled skills use the published HCS-28 baseline adapter ids, weights, and denominator rules directly
• MCP configuration trust uses the same HCS-style adapter, weight, and contribution-mode pattern locally
• top-level Codex plugin trust uses the same HCS-style adapter, weight, and contribution-mode pattern locally

Current local specs:

• Skill Trust Local Draft
• MCP Trust Draft
• Codex Plugin Trust Draft

This keeps the quality grade and the trust score separate. Signals like SECURITY.md remain visible, but their weight is now a named adapter weight rather than an inferred side effect of raw category points.

Quick Start For Contributors

git clone https://github.com/hashgraph-online/hol-guard.git
cd hol-guard
uv sync --extra dev --extra cisco --group cisco-mcp
pytest -q

Use uv sync --extra dev --python 3.10 when you need the lean baseline path without the Cisco MCP extra.

Install The Package You Need

Lean baseline install

Guard package:

pip install hol-guard

Scanner package:

pip install plugin-scanner

The lean baseline keeps Python 3.10+ support intact. It includes the shipped cisco-ai-skill-scanner integration on Python 3.10 through 3.14 and directly pins LiteLLM 1.93.0 so bare pip and pipx installs cannot drift to an unverified LiteLLM release.

Resolver-safe Cisco extra

Install the Cisco extra on Python 3.11 through 3.14 when you want to explicitly select the Cisco dependency surface in addition to the baseline skill scanner:

pip install "hol-guard[cisco]"

pip install "plugin-scanner[cisco]"

cisco-ai-mcp-scanner stays in the repo-controlled cisco-mcp uv dependency group and now pins Cisco's LiteLLM 1.93.0-compatible release so Docker and CI can install full Cisco coverage natively on Python 3.11.4 through 3.14. The published cisco extra remains resolver-safe for pip users.

On Guard surfaces, the Cisco extra keeps the LiteLLM-dependent Cisco skill-scanner path on a patched resolver-safe version. Repo-controlled Docker and uv sync --extra dev --extra cisco --group cisco-mcp --python 3.13 installs add optional Cisco MCP evidence to hol-guard scan, hol-guard preflight, and hol-guard explain <path>. Use --cisco-mode {auto,on,off} to control that consumer-mode evidence path for local artifact scans. hol-guard run and Guard runtime prompt/file-read protection remain native Guard behavior in this pass.

Guard inventory snapshots can also carry Cisco MCP and skill-scanner status when a Hermes or OpenClaw inventory run explicitly enables those scanners. The Cloud evidence model records scanner source, status, redacted finding text, duration, mapped artifact ID, and risk component metadata without storing raw local paths or secrets.

Guard does not add Cisco AIBOM runtime integration in this pass. If AIBOM support returns later, it should stay on evidence or export surfaces rather than Guard blocking or approval logic.

Cisco package status

Credit to Cisco AI Defense for open-sourcing the packages below.

If you want both tools in one shell during local development:

pipx install hol-guard
pipx install plugin-scanner

Container-first environments can use the published image instead. The repo-controlled image installs a lock-derived Cisco dependency set on Python 3.13 so the container has full static Cisco coverage by default.

docker run --rm \
  -v "$PWD:/workspace" \
  ghcr.io/hashgraph-online/hol-guard:<version> \
  scan /workspace --format text

Command names by package:

hol-guard start
plugin-scanner verify .

DevContainer / Codespaces

Add HOL Guard to your devcontainer.json for automatic protection in VS Code Codespaces and remote dev containers:

{
    "features": {
        "ghcr.io/hashgraph-online/hol-guard/hol-guard:1": {}
    }
}

Options:

See devcontainer-features/hol-guard/README.md for details.

Ecosystem Support

Use --ecosystem auto (default) to scan all detected packages in a repository, or select a single ecosystem explicitly.

What The Scanner Checks

plugin-scanner supports a full quality suite:

• scan for full-surface security and release analysis
• lint for rule-oriented authoring feedback
• verify for runtime and install-surface readiness checks
• submit for artifact-backed submission gating
• doctor for targeted diagnostics and troubleshooting bundles

The scanner evaluates only the surfaces a plugin actually exposes, then normalizes the final score across applicable checks. A plugin is not rewarded or penalized for optional surfaces it does not ship.

CLI Usage

# Scan a plugin directory
plugin-scanner scan ./my-plugin

# Auto-detect all supported ecosystems inside a repo (default)
plugin-scanner scan ./plugins-repo --ecosystem auto

# Scan only Claude package surfaces
plugin-scanner scan ./plugins-repo --ecosystem claude

# Scan only native Kimi Code plugin surfaces
plugin-scanner scan ./plugins-repo --ecosystem kimi

# Scan a native DeepSeek Harness (DSH/Cordis) package
plugin-scanner scan ./dsh-plugin --ecosystem deepseek-harness

# List supported ecosystems
plugin-scanner --list-ecosystems

# Output JSON
plugin-scanner scan ./my-plugin --format json

# Write a SARIF report for GitHub code scanning
plugin-scanner scan ./my-plugin --format sarif --output plugin-scanner.sarif

# Fail CI on findings at or above high severity
plugin-scanner scan ./my-plugin --fail-on-severity high

# Require Cisco skill scanning with a strict policy
plugin-scanner scan ./my-plugin --cisco-skill-scan on --cisco-policy strict

# Require optional Cisco MCP static analysis
plugin-scanner scan ./my-plugin --cisco-mcp-scan on

Use the bare plugin-scanner ./my-plugin form only for compatibility with older automation. New scripts and docs should prefer explicit subcommands so scan, lint, verify, submit, and doctor have predictable help, flags, and output.

Quality Suite Commands

# Summary scan (legacy form still works)
plugin-scanner scan ./my-plugin --format json --profile public-marketplace

# Scan a multi-plugin repo from the marketplace root
plugin-scanner scan . --format json

# Rule-oriented lint (with optional mechanical fixes)
plugin-scanner lint ./my-plugin --list-rules
plugin-scanner lint ./my-plugin --explain README_MISSING
plugin-scanner lint ./my-plugin --fix --profile strict-security

# Runtime readiness verification
plugin-scanner verify ./my-plugin --format json
plugin-scanner verify . --format json
plugin-scanner verify ./my-plugin --online --format text

# Artifact-backed submission gate
plugin-scanner submit ./my-plugin --profile public-marketplace --attest dist/plugin-quality.json

# Diagnostic bundle
plugin-scanner doctor ./my-plugin --component mcp --bundle dist/doctor.zip

Codex Spec Alignment

The scanner follows the current Codex plugin packaging conventions more closely:

• local manifest paths should use ./ prefixes
• .agents/plugins/marketplace.json is the preferred marketplace manifest location
• root marketplace.json is still supported in compatibility mode
• interface metadata no longer requires an undocumented type field
• verify performs an MCP initialize handshake before probing declared capabilities

lint --fix preserves or adds the documented ./ prefixes instead of stripping them away.

For repo-scoped marketplaces, scan, lint, verify, and doctor can target the repository root directly. submit remains intentionally single-plugin so the emitted artifact points at one concrete plugin package.

Config + Baseline Example

# .plugin-scanner.toml
[scanner]
profile = "public-marketplace"
baseline_file = "baseline.txt"
ignore_paths = ["tests/*", "fixtures/*"]

[rules]
disabled = ["README_MISSING"]
severity_overrides = { CODEXIGNORE_MISSING = "low" }

Example Output

🔗 Plugin Scanner v2.0.0
Scanning: ./my-plugin

── Manifest Validation (31/31) ──
  ✅ plugin.json exists                           +4
  ✅ Valid JSON                                   +4
  ✅ Required fields present                      +5
  ✅ Version follows semver                       +3
  ✅ Name is kebab-case                           +2
  ✅ Recommended metadata present                 +4
  ✅ Interface metadata complete if declared      +3
  ✅ Interface links and assets valid if declared +3
  ✅ Declared paths are safe                      +3

── Security (16/16) ──
  ✅ SECURITY.md found                            +3
  ✅ LICENSE found                                +3
  ✅ No hardcoded secrets                         +7
  ✅ No dangerous MCP commands                    +0
  ✅ MCP remote transports are hardened           +0
  ✅ No approval bypass defaults                  +3

── Operational Security (0/0) ──
  ✅ Third-party GitHub Actions pinned to SHAs    +0
  ✅ No write-all GitHub Actions permissions      +0
  ✅ No privileged untrusted checkout patterns    +0
  ✅ Dependabot configured for automation surfaces +0
  ✅ Dependency manifests have lockfiles          +0

── Skill Security (15/15) ──
  ✅ Cisco skill scan completed                   +3
  ✅ No elevated Cisco skill findings             +8
  ✅ Skills analyzable                            +4

Findings: critical:0, high:0, medium:0, low:0, info:0

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Final Score: 100/100 (A - Excellent)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Report Formats

Scanner Signals

The scanner currently detects or validates:

• Hardcoded secrets such as AWS keys, GitHub tokens, OpenAI keys, Slack tokens, GitLab tokens, and generic password or token patterns
• Dangerous MCP command patterns such as rm -rf, sudo, curl|sh, wget|sh, eval, exec, and PowerShell or cmd /c shells
• Insecure MCP remotes, including non-HTTPS endpoints and non-loopback HTTP transports
• Risky Codex defaults such as approval bypass and unrestricted sandbox defaults inside shipped plugin config or docs
• Publishability issues in interface metadata, HTTPS links, and declared asset paths
• Workflow hardening gaps including unpinned third-party actions, write-all, privileged checkout patterns, missing Dependabot, and missing lockfiles
• Skill-level issues surfaced by Cisco skill-scanner when the optional integration is installed
• Static MCP findings surfaced by Cisco mcp-scanner when the repo-controlled Docker image or cisco-mcp uv group is installed

CI And Automation

Add the scanner to a plugin repository CI job:

permissions:
  contents: read
  security-events: write

jobs:
  scan-plugin:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: hashgraph-online/ai-plugin-scanner-action@v1
        with:
          plugin_dir: "."
          mode: scan
          profile: public-marketplace
          min_score: 80
          fail_on_severity: high
          format: sarif
          upload_sarif: true

For a multi-plugin repo, the same workflow can stay pointed at plugin_dir: "." as long as the repository has .agents/plugins/marketplace.json with local ./plugins/... entries.

For repo-controlled validation in this repository, Linux jobs that target full coverage install the cisco extra on Python 3.12, while the baseline matrix keeps Python 3.10 compatibility explicit.

Local pre-commit style hook:

repos:
  - repo: local
    hooks:
      - id: plugin-scanner
        name: Plugin Scanner
        entry: plugin-scanner
        language: system
        types: [directory]
        pass_filenames: false
        args: ["./"]

GitHub Action

The Marketplace action lives in the dedicated repository hashgraph-online/ai-plugin-scanner-action.

The Marketplace action bundle is maintained in action/ and published automatically to hashgraph-online/ai-plugin-scanner-action by .github/workflows/publish-action-repo.yml after each PyPI release. The legacy alias hashgraph-online/hol-codex-plugin-scanner-action remains available for existing workflows. When you run the scanner in your own job instead of the packaged action, install plugin-scanner[cisco] on Python 3.11 through 3.14 for the resolver-safe Cisco skill-scanner path. Use the repo-controlled Docker image or uv sync --extra dev --extra cisco --group cisco-mcp --python 3.13 when you also need Cisco MCP coverage with CISCO_MCP_SCAN=auto or CISCO_MCP_SCAN=on.

Plugin Author Submission Flow

The action can also handle submission intake. A plugin repository can wire the scanner into CI so a passing scan opens or reuses a submission issue in awesome-codex-plugins.

It also emits automation-friendly machine outputs:

• score, grade, grade_label, max_severity, and findings_total as GitHub Action outputs
• a concise markdown summary in the job summary by default
• an optional machine-readable registry payload file for downstream registry, badge, or awesome-list automation

The intended path is:

1. Add the scanner action to plugin CI.
2. Require min_score: 80 and a severity gate such as fail_on_severity: high.
3. Enable submission mode with a token that has issues:write on hashgraph-online/awesome-codex-plugins.
4. When the plugin clears the threshold, the action opens or reuses a submission issue.
5. The issue body includes machine-readable registry payload data, so registry automation can ingest the same submission event.

Example:

permissions:
  contents: read

jobs:
  scan-plugin:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6

      - name: Scan and submit if eligible
        id: scan
        uses: hashgraph-online/ai-plugin-scanner-action@v1
        with:
          plugin_dir: "."
          min_score: 80
          fail_on_severity: high
          submission_enabled: true
          submission_score_threshold: 80
          submission_token: ${{ secrets.AWESOME_CODEX_PLUGINS_TOKEN }}

      - name: Print submission issue
        if: steps.scan.outputs.submission_performed == 'true'
        run: echo "${{ steps.scan.outputs.submission_issue_urls }}"

submission_token is required when submission_enabled: true. This flow is idempotent. If the plugin repository was already submitted, the action reuses the existing open issue instead of opening duplicates by matching an exact hidden plugin URL marker in the existing issue body.

Registry Payload For Plugin Ecosystem Automation

If you want to feed the same scan into a registry, badge pipeline, or another plugin ecosystem automation step, request a registry payload file directly from the action:

permissions:
  contents: read

jobs:
  scan-plugin:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6

      - name: Scan plugin
        id: scan
        uses: hashgraph-online/ai-plugin-scanner-action@v1
        with:
          plugin_dir: "."
          format: sarif
          output: ai-plugin-scanner.sarif
          registry_payload_output: ai-plugin-registry-payload.json

      - name: Show trust signals
        run: |
          echo "Score: ${{ steps.scan.outputs.score }}"
          echo "Grade: ${{ steps.scan.outputs.grade_label }}"
          echo "Max severity: ${{ steps.scan.outputs.max_severity }}"

      - name: Upload registry payload
        uses: actions/upload-artifact@v6
        with:
          name: ai-plugin-registry-payload
          path: ${{ steps.scan.outputs.registry_payload_path }}

The registry payload mirrors the submission data used by HOL ecosystem automation, so one scan can drive code scanning, review summaries, awesome-list intake, and registry trust ingestion.

Development

pip install -e ".[dev,cisco]"
ruff check src tests
ruff format --check src
pytest -q
python -m build

Use pip install -e ".[dev]" or uv sync --extra dev --python 3.10 when you need the lean baseline path without the Cisco MCP extra.

Repository Workflows

• Matrix CI for Python 3.10 through 3.13
• Package publishing via the publish.yml workflow
• OpenSSF Scorecard automation for repository hardening visibility

Security

For disclosure and response policy, see SECURITY.md.

Contributing

Contribution guidance lives in CONTRIBUTING.md.

Maintainers

Maintained by HOL.

Example: HOL Registry Broker Plugin

The HOL Registry Broker Codex Plugin bridges Codex plugins with the HOL Universal Registry, providing agent discovery, trust signals, and verified identity on Hedera.

HOL Registry scores: Trust 80 / Review 83 / Enforce 74

🔗 Plugin Scanner v2.0.0
Scanning: ./registry-broker-codex-plugin

── Manifest Validation (31/31) ──
  ✅ plugin.json exists                           +4
  ✅ Valid JSON                                   +4
  ✅ Required fields present                      +5
  ✅ Version follows semver                       +3
  ✅ Name is kebab-case                           +2
  ✅ Recommended metadata present                 +4
  ✅ Interface metadata complete if declared      +3
  ✅ Interface links and assets valid if declared +3
  ✅ Declared paths are safe                      +3

── Security (24/24) ──
  ✅ SECURITY.md found                            +3
  ✅ LICENSE found                                +3
  ✅ No hardcoded secrets                         +7
  ✅ No dangerous MCP commands                    +3
  ✅ MCP remote transports are hardened           +3
  ✅ No approval bypass defaults                  +5

── Operational Security (20/20) ──
  ✅ Third-party GitHub Actions pinned to SHAs    +5
  ✅ No write-all GitHub Actions permissions      +5
  ✅ No privileged untrusted checkout patterns    +3
  ✅ Dependabot configured for automation surfaces +4
  ✅ Dependency manifests have lockfiles          +3

── Best Practices (15/15) ──
  ✅ README.md found                             +5
  ✅ Skills directory present                    +3
  ✅ SKILL.md frontmatter valid                  +4
  ✅ No committed .env                           +2
  ✅ .codexignore found                          +1

── Marketplace (15/15) ──
  ✅ marketplace.json valid                      +5
  ✅ Policy fields present                       +5
  ✅ Marketplace sources are safe                +5

── Skill Security (15/15) ──
  ✅ Cisco skill scan completed                  +3
  ✅ No elevated Cisco skill findings            +8
  ✅ Skills analyzable                           +4

── Code Quality (10/10) ──
  ✅ No eval or Function constructor             +5
  ✅ No shell injection patterns                 +5

Findings: critical:0, high:0, medium:0, low:0, info:0

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Final Score: 130/130
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Plugins that pass the scanner with a high score are candidates for listing in the HOL Plugin Registry.