Pre-push local review
Review your working diff locally with the lgtm CLI before pushing — catch issues before the PR opens, save round-trips with reviewers, faster iteration.
You push a PR, wait for CI + reviewer + AI bot, eventually get comments back, fix, push again. Cycle takes hours per change. Pre-push review collapses it to seconds.
The workflow
Install the lgtm CLI globally (`npm i -g @tarin/lgtm-cli`). Sign in once (`lgtm login` — opens your browser for GitHub OAuth, stores a session token). From any repo, run `lgtm review` to review the current working diff against the default branch.
Output: same 6-agent review you'd get on a PR, posted to stdout instead of GitHub. Findings color-coded by severity, grouped by file, with line numbers matching your local checkout. JSON mode (`lgtm review --json`) outputs machine-readable for piping into pre-push git hooks or CI scripts.
Time: 30-90 seconds end-to-end, same as the PR review. The diff size influences this more than anything else. For huge diffs (5000+ lines), the CLI streams agent progress to terminal so you can watch it work.
Why pre-push is better than post-PR for fast feedback
Post-PR feedback latency: open PR → wait for CI (5-15 min) → wait for AI review (1-2 min) → wait for human reviewer (hours to days) → see comments → context-switch back to the change → fix → push again. Even the fast path takes 20+ minutes of clock time and several context switches.
Pre-push: write code → save → `lgtm review` → see findings in 60s → fix → repeat. Tight loop, no context switching, no PR notifications cluttering your reviewers' inbox with iterative work-in-progress changes.
The economic point: senior eng review time is the most expensive thing in your eng org. Anything that absorbs feedback BEFORE the human reviewer is involved saves them time. Pre-push review absorbs ~80% of review feedback before any human sees the PR.
Git-hook integration (optional)
Install as a pre-push hook (Husky or pre-commit framework). On `git push`, the hook fires `lgtm review --json --fail-on=blocker`. If any blocker-severity findings are detected, push is aborted with the relevant lines highlighted.
Severity threshold is tunable — `--fail-on=critical` only blocks on critical-severity bugs, `--fail-on=any` blocks on any finding. Most teams set a moderate threshold (block on blocker/critical, warn on others).
Skip the hook in emergencies: `git push --no-verify` bypasses. Trust your engineers to skip responsibly — the hook is a safety net, not a wall.
What the CLI reviews vs what the PR review covers
Pre-push review uses the SAME 6 agents (Bugs, Security, Performance, Readability, Best-Practices, Documentation) + synthesizer. Same models. Same context retrieval if your repo is indexed.
The only difference: the CLI uses your local working diff (uncommitted changes too, if you pass `--include-uncommitted`), while the PR review uses the GitHub diff. Otherwise functionally identical.
Quota use: pre-push reviews count toward your monthly quota (20/mo on Free, unlimited on Pro). Each CLI review is one review billed.
Configuration examples
# Review working diff against default branch
lgtm review
# Output JSON for scripting
lgtm review --json > review.json
cat review.json | jq '.findings | length'
# Use in pre-push hook
lgtm review --json --fail-on=blocker || exit 1// .husky/pre-push
#!/usr/bin/env sh
. "$(dirname "$0")/_/husky.sh"
# Run LGTM review; abort push on blocker findings
lgtm review --json --fail-on=blocker
if [ $? -ne 0 ]; then
echo "❌ LGTM found blocker-severity issues. Fix or use --no-verify to bypass."
exit 1
fiRead the lgtm CLI deep dive
Pre-push review · Husky hook · JSON output · session-based auth
Go to the product pageFAQs
Does pre-push review work offline?
No — the CLI calls our API which calls your BYOK provider. Both require internet. The CLI does cache your session token locally so authentication doesn't need a roundtrip.
Will pre-push hook slow down git push?
Yes — by 30-90s. For most workflows that's fine (push isn't a hot path). For repos where push speed matters (large monorepos with many tiny commits), use the hook with `--fail-on=blocker-critical` only so cheap changes aren't reviewed.
What about reviewing a specific PR from the CLI?
Yes — `lgtm review --pr <number>` triggers a fresh review on an existing PR. Useful for forcing a re-review after a force push without waiting for the webhook.
Does the CLI work with multiple LGTM accounts?
One signed-in account at a time. `lgtm logout` drops the session, then `lgtm login` signs into a different account. Account-switching automation isn't supported (intentionally — multi-account scripting is a credential-confusion footgun).
CLI version compatibility?
The CLI versions independently from the LGTM API. Run `lgtm --version` to see installed; the API tells you the minimum supported version. Below that, you get a 'please update' message with the latest install command.
Related across LGTM
lgtm CLI feature page
Full CLI surface — install, login, review, repo, security commands.
AI code review explained
What the CLI invokes server-side when you run `lgtm review`.
TS code review
What pre-push CLI review looks like on a TypeScript repo specifically.
Python code review
Same on Python — pip / Poetry / uv all work the same with the CLI.
Related use cases
Use LGTM as a CI gate
Configure LGTM's review verdict as a required Check Run in branch protection. A failed review blocks the merge until findings are resolved — automated quality gate, no human bottleneck.
Onboard a monorepo to AI code review
Connect a 1k–100k-file monorepo to LGTM in under 10 minutes. Tree-sitter indexes all 12 languages, PageRank ranks cross-package context, BYOK keeps per-PR cost manageable.
Welcome OSS contributors with AI review
For open-source projects: LGTM's review on every incoming PR catches bugs early, gives first-time contributors fast feedback, and frees maintainers from style/triage work.