git-lrc: AI Code Review That Runs on Every Git Commit

The problem git-lrc targets: AI agents that commit without telling you

The README opens with a blunt framing: GenAI is "a race car without brakes," and AI agents "silently break things" by removing logic, relaxing constraints, introducing expensive cloud calls, leaking credentials, and changing behavior. The failure mode it names is not bad syntax. It is a diff that looks plausible, passes a glance, and changes runtime behavior in a way nobody notices until production.

The stated answer is a hook on git commit that runs an AI review on every diff before it lands. The README claims a 60-second setup and calls the tool completely free. The intended user is a developer or small team already using AI coding agents, where the volume of generated code has outgrown manual reading. The README also argues against waiting for a pull request: by PR time the faulty code is already committed and pushed, so the review arrives after the moment when the author could have fixed it quietly.

That argument is the project's real thesis, and it is a positioning choice rather than a technical one. A commit-time reviewer competes for the same attention as a pre-commit linter, and it has to be fast enough that nobody adds --no-verify to their muscle memory. The README's emphasis on "micro" reviews and a 60-second summary deck reads as an attempt to keep the interruption small.

How the commit hook, Issue Navigator and Summary Deck fit together

The repository layout shows the moving parts: hooks/, gitops/, review/, storage/, network/, ui/, interactive/, and a blastradius/ directory backed by a dependency on github.com/HexmosTech/blastradius. The binary is named lrc, set in the Makefile as BINARY_NAME=lrc.

Configuration is TOML. The repo ships .lrc.toml.sample at the top level and a .lrc/ directory, and go.mod lists github.com/knadh/koanf/v2 with the koanf TOML parser, so the config is read through koanf rather than a hand-rolled parser. Storage uses modernc.org/sqlite, a pure-Go SQLite implementation, which is why the binary has no cgo SQLite dependency to fight with at install time. Concurrency is guarded by github.com/gofrs/flock, and the terminal interface is built on charm.land/bubbletea/v2 with golang.org/x/term. Ignore handling uses github.com/sabhiram/go-gitignore, and the CLI surface is github.com/urfave/cli/v2.

The review output is not a wall of text. The README describes an Issue Navigator that groups findings across "10 risk categories and 100+ patterns," filterable by severity (Critical, Warning, Info), by category and subcategory, and by type and area (Bug, Code Smell, Reliability, Security). Each finding can be copied or sent to Claude to close the fix loop, and thumbs up/down on a finding is described as tuning future reviews. Separately, each completed review produces a Summary Deck: a short slide summary of what changed, why, and which risks were flagged. The README pairs this with Git Log Tracking for institutional memory.

The honest read: the quality of the whole system rests on the review prompt and the pattern catalogue, neither of which is visible from the repository layout. The UI is well specified in the README; the review logic is not.

Installing git-lrc and running a first review

The README gives a one-line install for Linux and macOS using the project's own package manager, ipm. The command downloads an installer script and then installs the HexmosTech/git-lrc package.

# Try it now (Linux/macOS)
curl -L https://hexmos.com/ipm-install | bash && ipm i HexmosTech/git-lrc

Piping a remote script into bash is a real decision, not a formality. If that matters to you, the repository also has a Makefile with build targets, and go.mod declares go 1.25.13, so a source build is the alternative path. The README points Windows users and anyone wanting alternative installs to a Get Started section that the truncated README does not include here.

Configuration is TOML and the repository ships a sample rather than a live file. Copy the sample into place before the first run.

cp .lrc.toml.sample .lrc.toml

After that, the trigger is the commit itself. There is no separate review command described in the README: you stage a change and commit, and the hook runs the review before the commit lands. The README's own framing is that every commit is scanned automatically. If a review does not appear on your first commit, the first thing to check is whether the hook was installed into the right git directory, which is exactly what the repository's test-hooks-worktree and test-hooks-global Makefile targets exist to exercise.

One detail worth noting for anyone installing on a fresh machine: .env.example is not user configuration. It holds Backblaze B2 keys (B2_KEY_ID, B2_APP_KEY, B2_BUCKET_NAME, B2_BUCKET_ID) used by the maintainers to publish releases. Do not copy it expecting it to configure reviews.

Where git-lrc gets in the way

The design puts an AI call on the critical path of git commit. That is the point, and it is also the main cost. Any network latency, provider outage, or rate limit now sits between a developer and their commit. The README does not document an offline mode, a timeout policy, or what the hook does when the AI provider is unreachable. Git's own escape hatch, --no-verify, bypasses hooks entirely, so a slow or flaky review does not block work so much as train people to skip it.

The second constraint is data flow. Reviewing a diff means sending that diff to a configured AI provider. The README's own example of what the tool catches includes leaked credentials and sensitive material in log statements, which means the review pipeline itself sees secrets before anyone has a chance to rotate them. The repository does carry a .gitleaks.toml and a gitleaks secret-scanning workflow, but a secret scanner in CI is not the same as a policy about what leaves the machine at commit time. The README does not describe a redaction step.

Third, the review surface is the diff. Changes that are only wrong in combination with code outside the diff are the classic blind spot of any diff-scoped reviewer, and nothing in the README claims otherwise. The blastradius/ directory and the HexmosTech/blastradius dependency suggest some attempt to reason about impact beyond the changed lines, but the README does not explain what that component does, and a reader should not assume it does more than the documentation states.

Finally, the licence. The repository metadata reports NOASSERTION, not an SPDX identifier. LICENSE.md exists at the top level alongside CONTRIBUTOR_LICENSE_AGREEMENT.md, so there is a real agreement to read, but the machine-readable signal is absent. For a free tool this is a small friction; for a company with a licence review process it is a blocker until someone reads the file.

How git-lrc differs from pre-commit linters and CI review bots

The closest comparison is a pre-commit framework such as pre-commit running deterministic linters. The difference is in what each can catch. A linter applies fixed rules and produces the same verdict every time; it will catch a missing error check or a formatting violation and will never catch a relaxed constraint or a subtly changed branch condition. git-lrc's value proposition is precisely the class of change that has no rule: behavior that shifted while the syntax stayed valid. The trade is determinism and speed. Linters run locally in milliseconds with no external call; git-lrc needs a model and a network round trip.

Against CI review bots, the difference is timing and scope. A CI bot reviews after the push, with the full repository available, and can be made a required check on a pull request. git-lrc reviews before the commit exists, which is earlier but also narrower, and it produces advisory output rather than a gate. The README makes this argument directly: by PR time the code is already pushed and visible. That is a fair point about cost of cleanup, but it also means git-lrc cannot replace a CI gate. It is a pre-flight check, not an enforcement mechanism.

Against IDE extensions, the README's own objection is coverage. An extension runs when the developer chooses to run it. A commit hook runs on the path everyone already takes. That is a genuine difference in trigger reliability, and it is the strongest argument in the README for the hook model over a plugin.

Release cadence, upgrade cost and the licence question

The project is not archived, and the last push was on 2026-09-05, which is recent. Releases v0.6.9 and v0.6.10 both landed on 2026-08-24, and v0.6.11 followed on 2026-09-05. That is a fast patch cadence on a 0.6 line, which tells you the interface is still moving. Expect to re-read .lrc.toml.sample after upgrades rather than assuming your config keys are stable.

The Makefile shows the upgrade and release machinery is taken seriously: security-govulncheck, security-osv, security-gitleaks, security-sbom, security-sbom-cyclonedx, security-sbom-spdx, release-preflight, and release-notes-check are all declared targets. Dependabot is enabled according to the repository's own badge graphic. None of that guarantees anything about the code, but it does mean vulnerabilities and dependency drift are being watched by the maintainers rather than ignored.

On licence, the metadata says NOASSERTION. The repository contains LICENSE.md and CONTRIBUTOR_LICENSE_AGREEMENT.md, and the README markets the tool as completely free. Free to use and permissively licensed are not the same claim, and the only way to resolve it is to read LICENSE.md. This is not legal advice; it is a statement that the machine-readable licence field is empty and that a company doing licence review will treat that as unresolved until a human reads the file.

Editorial conclusion

git-lrc fits teams already committing AI-generated code who want a review pass before the push, not after the pull request. It does not fit anyone who needs a documented licence for procurement, because the repository carries NOASSERTION rather than an SPDX identifier, and it does not fit teams who cannot send diffs to the configured AI provider. Before adopting it, read LICENSE.md in full, check whether the .lrc.toml.sample config supports the provider you use, and confirm the commit hook behaves correctly in your worktrees by running the repository's own test-hooks-worktree target.

Frequently asked questions

Official sources

1. HexmosTech/git-lrc on GitHub
2. Issues
3. Project website
4. README
5. Releases