Features

Last updated 11 November 2026.

What does MergeSafe do?

MergeSafe reviews every commit on your GitHub pull requests for bugs and security problems, guards your dependencies for free, turns Sentry errors into tested fixes and checks new issues against your code. Each item below links to its docs.

Supply chain

• Advisory check: when a new advisory names a package you use, MergeSafe reads your code to see whether you’re affected, opens an issue if so, and closes it once you’re not.
• Dependency gate (free): flags a pull request that adds a known-vulnerable (CVE) or malicious npm or PyPI version, on every pull request, with or without a review; with a review, also a lookalike, made-up or otherwise risky package. On for every repository and advisory by default, so it never blocks a merge; one setting makes it blocking or turns it off. Every sign-off goes in an audit log you can export.
• Dependency findings (free, in every review): new or changed npm and PyPI versions with known vulnerabilities (CVEs) or malware, and changed lockfile sources or hashes.
• CI workflow checks: unpinned actions, risky pull_request_target use, broad permissions and secrets passed to untrusted steps.

Reviews

• A review on every commit: a summary, inline findings and a check run on the pull request.
• Two levels, Strong and Ultra, per organization or per repository.
• Expert add-ons for a deeper security or logic review on any level.
• A security review on every level: injection, access control, secrets, SSRF, XSS and more.
• Any language, with extra checks for Go and Ruby, and bugs proved by running code for Python, JavaScript and TypeScript.
• Your rules in AGENTS.md and .cursor/rules/ applied to every review.
• Follow-up reviews of only what changed, half price for small ones on Strong.

Reading a review and merging

• A merge readiness score from 1 to 5.
• Severity P0 to P3; only P0 and P1 block.
• The mergesafe-review check, which you can make required.
• Approval of pull requests that pass, on by default.
• Reply to a finding to dispute it or mark it fixed.
• Learns from your replies. A reasoned reply can become a rule for the repository, and later reviews follow it.
• Asks when it isn’t sure. When a P2 or P3 finding may be intended, MergeSafe asks the author (“Is this intentional?”) instead of flagging it. Questions don’t count toward the score; P0 and P1 are never asked. On by default; an admin can turn it off.
• Already on your branch. A finding in code the pull request didn’t touch is labeled “already on your branch”, keeps its severity, and is left out of the pull request’s score, so it never blocks. With GitHub Issues connected, it is filed as an issue (P1 and up by default; you choose the bar).
• A prompt with each finding to paste into your coding agent.

Controlling reviews

• When reviews run: every commit, on open only, or manual only.
• Whose pull requests are reviewed.
• @mergesafe commands in pull request comments.
• Large pull requests: MergeSafe asks before reviewing one over 2,000 lines.
• Recommendations: seven GitHub security settings checked per repository.

Beyond pull requests

• Issue triage (free for 20 a day and 100 a month, then 5¢ each): new GitHub, Jira and Linear issues checked against your code.
• Sentry: errors turned into GitHub issues, with optional root-cause analysis.
• Sentry fixes (Python for now): we reproduce the error and prove the fix before opening a pull request; when we can’t, the pull request says it is unverified. Every fix gets a Strong review, and anyone who can merge can do it in one click from Slack or email.
• Slack: updates and commands in your channel.
• Full audit of a repository’s default branch, free when you start.

Billing and limits

• Prepaid, per review: no seats, $20 free to start (valid 30 days), never charged for skipped or failed reviews.
• Spending limits per day, week and month for the organization, and daily and monthly per repository and per developer.
• Auto-refill with a monthly limit you set, and an optional daily one, never above your balance cap.

Your organization and data

• Admin and Member roles, and requests to join.
• Repo visibility: members see only repositories they can access on GitHub.
• Data retention: code-derived data encrypted per repository and deleted on uninstall.

For coding agents and CI

• API keys: start a review from CI or a script.
• MCP server: your coding agent reads findings, fixes them and asks for a re-review.

Next: How a review works →