Magga

Prove that a code change actually works, whether an AI agent wrote it or a stranger's pull request did.

Magga runs the change in a sandbox and checks it against reality instead of scoring how plausible it looks. The name is the Pali word for "the path": a change has to walk the path (build, test, prove) before it is trusted.

Why this exists

Two problems, one root cause.

A coding agent tells you "fixed the crash" and you have no fast way to know if that is true or if it just wrote something that looks right. At the same time, maintainers are buried under pull requests that were generated the same way: plausible on the surface, hollow underneath. Scoring tools try to guess which ones are real by reading them. But slop is written to read well, so reading it is exactly the wrong test.

Magga does not read and guess. It builds the change and runs it.

Related MCP server: Petamind MCP

The core idea: the change earns its verdict by execution

The signal a plain reviewer cannot get is whether a change is backed by a test that actually exercises it. Magga's main check is simple and hard to fake:

If a change adds a test, that test must fail on the code before the change and pass on the code after it.

A genuine fix comes with a test that reproduces the bug (fails on the old code) and closes it (passes on the new code). A hollow change comes with a test that passes either way, because it does not really cover anything. No amount of good-looking prose survives this, because it is decided by running the code.

On top of that, Magga confirms the change builds and the existing suite still passes, so a break or a regression is caught before anything else.

Two ways to use it, one engine

Magga is one verification engine behind a few thin surfaces.

For developers, as an MCP tool

Point your coding agent at Magga and it can prove its own work before telling you it is done. Register the server with Claude Code, Codex, or opencode:

{
  "mcpServers": {
    "magga": { "command": "npx", "args": ["-y", "@8nobletruths/magga", "mcp"] }
  }
}

After the agent edits code, it calls the verify_change tool. Magga builds, runs the tests, runs the fails-on-base check, and returns a verdict with evidence. If the change is not verified, the agent iterates instead of claiming success.

For maintainers, as a GitHub Action

Drop the action into a repo and every incoming pull request is checked automatically. It posts a verdict and a label (verified, needs-info, or likely-slop) with the evidence behind it, and surfaces only the pull requests worth your time.

# .github/workflows/magga.yml
name: magga
on: pull_request
permissions:
  contents: read
  pull-requests: write
  issues: write
jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
          ref: ${{ github.event.pull_request.head.sha }}
      - uses: 8NobleTruths/magga@v0.3.0
        # accepting untrusted outside pull requests? isolate them:
        # with:
        #   sandbox: true

By default the build and tests run directly on the runner, which is fine for pull requests you trust (your own, or a private repo). To accept untrusted outside pull requests, set sandbox: true: the pull request's setup, build, and tests then run inside an ephemeral Docker container with no network, resource limits, and none of the runner's secrets, while Magga's own git operations stay on the host. You can pin the image with image: (it defaults to a per-language image).

From the command line

magga verify .                          # verify the current branch against its merge base
magga verify . --base main --head HEAD
magga verify . --json                   # machine-readable verdict

How a verdict is reached

                MCP tool          GitHub Action          CLI
             verify_change          PR gate           magga verify
                   \                    |                  /
                    \                   |                 /
                     ------------- MAGGA CORE ------------
                        sandbox    isolated build + run
                        checks     build
                                   test suite (regression)
                                   test-fails-on-base (novelty)
                        verdict    status + evidence

Statuses:

• verified builds, the suite passes, and the new test fails on the base and passes on the head.

• needs-info builds and passes, but nothing proves the change is real (for example a fix with no covering test). Magga asks a specific question rather than guessing.

• likely-slop does not build, breaks the suite, or ships a test that passes on the base too.

Install

npx @8nobletruths/magga verify .        # run without installing
npm install -g @8nobletruths/magga      # or install the CLI (the command is `magga`)

Supported project types: Rust (Cargo), Go, Solidity (Foundry), JavaScript/TypeScript (npm/pnpm and Deno), Python (pytest), and C/C++ (Make and CMake) are exercised end to end in CI. There is also best-effort detection for Java (Maven and Gradle), Ruby, PHP, C#/.NET, Elixir, Swift, and Zig. Anything the defaults miss can be set in .magga.json.

Configuration

Detection covers the common cases. When your repo needs something else, override it with a .magga.json at the root (every field optional):

{
  "setup": "npm ci",
  "build": "cargo build --release",
  "test": "cargo nextest run",
  "testMarkers": ["tests/", "_test.rs"]
}

setup runs once before the checks (for example to install dependencies) and again in the base worktree during the novelty check. Commands can be a string or an array of arguments. The same overrides are available as flags: --setup, --build, --test. Flags win over .magga.json, which wins over detection.

Status

All three surfaces work today: the CLI, the MCP server (Claude Code, Codex, opencode), and the GitHub Action. Detection is proven in CI for Rust, Go, Solidity (Foundry), JavaScript/TypeScript, Python, and C/C++, with best-effort detection for several more and per-repo overrides in .magga.json. Untrusted pull requests can be isolated in a Docker container with --sandbox (or sandbox: true on the Action). Published as @8nobletruths/magga.

Still maturing: the novelty check runs the whole suite rather than the single affected test, and the set of supported project types will keep growing with use. See ROADMAP.md.

Contributing

Issues and pull requests are welcome. Magga verifies changes by running them, so a good pull request comes with a test that fails without your change and passes with it.

License

Apache-2.0. See LICENSE.