Open-source AI code review
arnx investigates code changes, generates and runs tests for suspected bugs, and lets you keep confirmed findings as regression checks.
Your agent writes the code.
arnx checks the behavior.
arnx 0.1.7 · Bring your own model keys, or use arnx cloud.
Python + Postgres / real review
A page limit dropped callouts while the polling state advanced.
The generated tests reproduced the failure. The owner accepted the finding and fixed the code.
Read the case study ↗Summary of a recorded run; not terminal output.
Docker, plus your own model key or arnx cloud with $5 of starting credit.
Install with npm (Node 20 or later):
npm install -g @arnx-dev/arnxThen, in your repository after a code change:
arnx init
arnx reviewThe first review sets up what it needs in a few minutes (it stops at 10). No separate setup step.
Rust is early and our least-tested runner. First setup compiles dependencies and test targets into an image that can take several GB. Try your crate and tell us what breaks ↗
01 / A real review
On a Python pipeline backed by Postgres, generated tests reproduced an inverted calculation, lost callouts beyond a page limit, and stale prices used in evaluation.
The owner marked 18 findings real. Their coding agent changed the product code; accepted test files stayed unchanged after acceptance.
Read the full case study ↗FINAL ACCEPTED-TEST CHECK
One owner-run case on a tuned development branch. Two known issues were missed. The counts describe the final test run, not bug-detection accuracy. Private source and raw execution logs are not published.
02 / How arnx works
Initialize the repository. The first review sets up only the projects the change touches; another project is set up when a later change touches it.
arnx initInvestigate the diff, generate targeted tests, and run them. Read the failures, open questions, and coverage gaps.
arnx reviewTriage real / intended / noise / rewrite, then accept useful tests. Use arnx prompt to hand the fix to your coding agent.
arnx triage
arnx accept
arnx promptRerun accepted regression tests in Docker without new model calls. Review and commit the tests with the fix.
arnx check03 / Why executable evidence matters
A review comment identifies a possible problem. An executed test gives you inputs, an expected result, and a failure you can investigate.
A test can misunderstand intent, depend on a brittle fixture, or fail at setup. Repetition and a second model do not replace developer review.
Accepted tests live in .arnx/tests/, pinned by
sha256 in .arnx/accepted-tests.json. Your own suite
never collects them; only arnx check runs them in a throwaway
copy. Read this model-written code first. Use
arnx check after the fix and on later changes, with
no additional model inference cost.
arnx runs each test 3 times, reruns failures on the code before the change, and has a second model confirm or dispute it. A failing test shows an assertion fails, not that the code is wrong. Model replies vary: two reviews of one change can differ.
Before/after outcomes are regression, pre-existing, new-code, changed or unknown. Only regression is evidence about the change: the test passes before and fails after, if its expectation is right.
Findings with one cause are grouped into an issue, most severe first, explained as input, actual, expected and why it matters. Issues backed by a confirmed test come pre-marked real; change what you disagree with. Marks are real, intended, noise or rewrite.
Tests that pass after the change but fail before it appear under “The change fixes”. Changed code no test touched is listed by name, and the review says “partly covered”. A passing check covers only the accepted tests.
arnx reviewing its own arnx remove command, before 0.1.
The test checks whether a recorded path can escape the repository.
Test and report quoted exactly from the README.
test("S2 accepted-test paths escaping the repository are never deleted", async () => {
const { base, repo, env } = setup();
const victim = join(base, "victim.txt");
put(victim, "keep me");
put(join(repo, ".arnx", "accepted-tests.json"), record({ "../victim.txt": {} }));
const cli = new Cli({ cwd: repo, env });
await withDocker("/nonexistent/docker", () => cli.run("remove", "--yes", "--tests"));
expect(existsSync(victim)).toBe(true);
});### Issue 1 · remove --yes can delete files outside the repository
- Actual: In S2, `../victim.txt` outside the repository was deleted. …
- Failing tests: F2, F4
### F2 · regression · confirmed by the second opinion
- Failure: `expect(received).toBe(expected)`
- Before the change (regression): passes on the code before the change (3 runs): the change broke it
- Second opinion: planRemove takes accepted-tests.json keys verbatim and applyRemove rmSync's join(repo, p), …The test failed in all 3 runs, passed before the change, and the second model agreed. We marked it real, kept it with arnx accept, fixed the code from the fix prompt and saw it pass in arnx check. Not every finding is like this one: in our own reviews, some confirmed issues tested behaviour we intended.
04 / Choose your setup
Tool calls, Docker tests, the before/after check, and report generation run on your machine. arnx cloud receives the diff, the files the agent reads, the tests it writes and their output, then passes them to its model providers. Read the data and execution boundaries.
05 / Built with developers
Report a bug, request framework support, or help make a generated test more useful. A small reproduction and clear expected behavior are a good place to start.
Keep the evidence
arnx 0.1.7 · Bring your own model keys, or use arnx cloud.