DevTrendsDeveloper trends
Accent color

sjh9714 /

mergewarden

Project URL Category JS Project Title A checkout-free GitHub Action that checks whether an AI agent's pull request stayed inside the boundaries it declared Project Description Coding agents open pull requests all day. Me…

DTData & operationsDTSoftware developmentDTAgent extensionDTCLIDTMCP serviceDTLinuxDTTerminalDTClaude CodeDTCodexDTCursor

Product images

About

Project URL Category JS Project Title A checkout-free GitHub Action that checks whether an AI agent's pull request stayed inside the boundaries it declared Project Description Coding agents open pull requests all day. MergeWarden checks each one against boundaries only your repository can define: did the PR stay inside its declared scope, did it edit agent instruction files, did it wire untrusted text into an agent prompt? Highlights It is deterministic — no LLM is called during analysis. Every finding carries a rule ID, a severity, the exact path, canonical evidence, and a stable finding ID, and the whole decision can be replayed locally with mergewarden replay. Two runs on the same commit always produce the same answer, which is what makes it usable as a merge gate. It never checks out or executes pull-request code. It reads the PR through the GitHub API only, and loads its policy from the exact base commit — so a pull request cannot weaken the policy that judges it by editing the config in its own branch. There is no checkout step in the workflow. It checks a layer that other tools do not. Workflow linters like zizmor check workflow correctness; LLM reviewers give semantic opinions. MergeWarden asks a different question: did this pull request cross a boundary specific to this repository — the scope the agent declared, the AGENTS.md / CLAUDE.md / .mcp.json files that steer every future agent run, or a path from a PR comment into an agentic workflow's prompt. The three are complementary. The design came from measurement, not intuition. We scanned 2,204 recently merged AI-agent pull requests on public repositories. Of the 349 that touched workflows or package manifests, 12.9% escalated workflow permissions and 17.5% introduced unpinned actions; 3.9% of all of them edited agent control-plane files. The default rules and the default detection lists are those findings, and every number reproduces from published queries. Zero runtime dependencies, MIT licensed, TypeScript. Example Code markdown Try it with one command — no token, no repository, no network. It analyzes an example pull request bundled inside the CLI, using the default policy: npx --yes mergewarden@0.5.0 demo Scan a real public pull request: npx --yes mergewarden@0.5.0 scan owner/repository#123 Install as a GitHub Action — note there is no actions/checkout step: name: MergeWarden on: pullrequest: permissions: contents: read pull-requests: read jobs: mergewarden: runs-on: ubuntu-latest steps: uses: sjh9714/mergewarden@v0.5.0 with: github-token: ${{ secrets.GITHUBTOKEN }} mode: warn An agent declares its intended scope in the pull-request body, and edits outside it become findings: Screenshots or Demo Videos One command, no token and no repository — this is a real npx run, not simulated output: The same command running (the full report is 95 lines, so it scrolls): The live pull request and Action run behind that report are public and can be inspected directly: A Simplified Chinese README is available at

Discovery history

  1. HelloGitHub·用户投稿

    Jul 25, 2026 · 1 observations

  2. 阮一峰周刊·用户投稿

    Jul 25, 2026 · 1 observations

Discuss this product