Scan every pull request

Get one comment on each pull request that changes agent config, in your own repos only.

Before you start

A GitHub repository you own or administer.
On a private repository, comments need a Pro licence in the secret DEEDGLASS_LICENCE. The scan and the job summary are free everywhere; public repositories need nothing.

Why two workflows

A pull request from a fork must never get a write token next to its own code. So the scan runs on pull_request with a read-only token and saves its result as an artifact, and a second workflow, started when the first one finishes, posts the comment. The second workflow never checks out the pull request’s code, and neither workflow uses pull_request_target.

1. The scan

name: Deedglass scan
on: [pull_request]
permissions:
  contents: read
jobs:
  scan:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
        with:
          fetch-depth: 0
          persist-credentials: false
      - uses: deedglass/scan-action@<full-commit-sha> # v1
        with:
          licence: ${{ secrets.DEEDGLASS_LICENCE }} # only needed for comments on private repos

The action scans the pull request’s head and its base, writes the grade and its deductions to the job summary, uploads SARIF where the token allows, and uploads result.json as an artifact kept for 3 days. Inputs: fail-under (fail the job below a grade, A to D), sarif (auto, always or never), dir and version. It runs only a deedglass binary whose sha256 is committed in the action’s repository, and it refuses Windows runners.

2. The comment

name: Deedglass comment
on:
  workflow_run: # zizmor: ignore[dangerous-triggers] never checks out PR code; the artifact is validated
    workflows: ["Deedglass scan"]
    types: [completed]
permissions: {}
jobs:
  comment:
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write
      actions: read
    steps:
      - uses: deedglass/scan-action/comment@<full-commit-sha> # v1

Pin both actions to a full commit sha in your repository; the tag goes in the comment.

What the comment step trusts

Nothing from the artifact is run. That is why the on: line tells zizmor, the workflow auditor, that this workflow_run trigger was reviewed. The job reads result.json as data: at most 256 KiB, known keys only, typed fields, ids checked by pattern and strings escaped. The pull request number and the changed files come from GitHub’s API, never from the artifact. It comments only when the pull request changes agent config: .mcp.json, .cursor/mcp.json, .vscode/mcp.json, **/claude_desktop_config.json, **/mcp_config.json, package.json, pyproject.toml, requirements*.txt, deedglass.yaml or policies/**. The comment is one sticky comment marked , edited on each push, with a link to how the grade is worked out.

What it doesn’t do

It comments only in the repository where you installed it, only when agent config or policy files change, and never in anyone else’s repository.
It doesn’t block a merge unless you set fail-under and make the scan a required check.
It never uses pull_request_target, and it sends no telemetry or scan data anywhere.
A forged result could get a private repository one comment without a licence; that is a known, accepted risk.