Local-First AI Code Review: Why Enterprise Codebases Can't Rely on Cloud Review Bots
Cloud review bots copy your diffs to vendor servers and ask for org-wide permissions. Here is how local AI code review and self-hosted PR review really differ, and what to verify before trusting either.
Every AI code review tool asks the same question of your codebase: how much of it are you willing to hand over? Most teams answer it by accident — they install a GitHub App, click authorize, and never look at where the code goes afterwards. For a side project that is fine. For a company whose source code is its main asset, it is a decision that security, legal and compliance have to sign off on before a single line gets reviewed.
Where does your code actually go?
A cloud review bot is a pipeline, not a magic box. Install one and the usual path looks like this:
- The app is granted access to your repositories — often read access to code, PR descriptions, comments and metadata.
- Every new or updated Pull Request ships the diff, and usually the surrounding file context, to the vendor's servers.
- That context is passed to a model, typically a third-party API the vendor resells.
- The prompt, the diff and the answer are stored — for debugging, for quality, sometimes for training, depending on the vendor's retention policy.
- The verdict comes back as a comment on your PR.
None of this is hidden; it is written in the privacy policy. The problem is that it leaves several copies of your source code living outside your perimeter, inside a system your security team neither runs nor audits.
Source code is not an ordinary dataset
Source code is the concentrated form of years of engineering decisions: proprietary algorithms, internal infrastructure details, the exact shape of your business logic. It is also the one asset that cannot be anonymized. You can tokenize a customer table, but a diff has to be read literally to be reviewed. Anything that can review it can read it.
Compliance, residency and contractual limits
In practice the objection rarely arrives as a philosophy debate. It arrives as a list:
- Frameworks and contracts that restrict where code may be processed — SOC 2 vendor reviews, ISO 27001, HIPAA, GDPR, FedRAMP, export controls.
- Customers who forbid their code, or anything derived from it, reaching third-party subprocessors.
- Data residency rules that require processing to stay in a specific jurisdiction.
- M&A and due diligence, where a buyer eventually asks a very simple question: who else holds a copy of this repository?
The permissions problem
Cloud bots need standing access: an org-wide app installation, admin approval, and scopes that let them post comments, labels and status checks. That privilege is permanent, it grows with every repository you connect, and it is exactly the kind of standing access an attacker looks for. Most enterprises handle it with an exception process, a threat model and a re-review whenever the scopes change — a process that can take longer than the pilot itself.
Secrets and customer data travel with the diff
A review does not only see your application logic. Test fixtures, seed data, migration files, config samples and log excerpts end up in diffs all the time. Once that diff has been shipped to a third-party server, a routine code review has quietly become a data incident.
What local-first AI code review actually means
A local-first AI reviewer inverts the default. Instead of your code traveling to the review service, the review comes to your machine:
- The diff and the surrounding code are read from your working copy, not fetched from a remote mirror.
- The reviewer can follow callers, open the tests and check neighbouring modules, because the whole repository is already on disk.
- Nothing is uploaded to a review vendor and nothing is retained on a review server afterwards.
- Authentication uses the credentials you already have — your own
ghlogin — instead of an org-wide app installation.
The privacy argument is the obvious one, but the technical argument is just as strong: a reviewer with the full repository in front of it answers questions a diff-only bot cannot, the same gap we describe in repository-aware reviews with Claude Code.
Local-first vs. self-hosted PR review
"Self-hosted" and "local" get used interchangeably in this category. They are two different architectures, and teams usually need to know which one they are actually buying.
- Self-hosted: the review service runs in your own infrastructure. Code stays inside your boundary, but you still deploy, upgrade and secure it, it still holds a copy of every PR it processes, and it still needs the same org-wide GitHub permissions.
- Local-first: the reviewer runs on the developer's machine with the developer's own credentials. There is no central service to breach, patch or pay for, but it only sees what is on that machine and it enforces nothing at the org level.
The two combine well: a local pass for the author before the Pull Request exists, plus CI checks or a self-hosted gate as the organization-wide rule. What does not work is assuming a local tool gives you org-wide enforcement, or that a self-hosted tool means no code ever moves.
The honest nuance: local-first is not automatically zero network
Be precise before telling your security team "it runs locally". Most local-first tools orchestrate a model you already subscribe to, and that model may well be a cloud API. What local-first guarantees is that no review vendor holds your code and no copy is retained on a third-party review server. Whether the model provider sees any context depends on which model you configure:
- A cloud model under your own agreement. Your existing vendor terms apply — the retention limits, training opt-outs and residency options you already negotiated for that subscription, with no additional party in the middle.
- A fully local model. Nothing leaves the machine at all, in exchange for some quality and speed.
The workable discipline is to write down, for every tool, three facts: what leaves the machine, to whom, and under which contract. That list is answerable. "It's local" is not.
How to evaluate any AI review tool's privacy claims
Whether a tool is cloud, self-hosted or local, the same seven questions usually settle it:
- Does the vendor store diffs or prompts, for how long, and are they used for training?
- What exactly goes out per PR — the diff only, or full files, history and repository metadata?
- What GitHub permissions does it need, and can it write to anything?
- Can access be revoked per repository, and does a deletion request actually delete the stored copies?
- Which subprocessors see the code, and are they named rather than generic?
- Is there a residency or on-premises option today, or is it a roadmap slide?
- For a local tool: does it upload anything at all, and which model endpoint does it call?
Where CodeCrab fits
CodeCrab is a native desktop app that reviews Pull Requests and local changes on your own machine:
- It pulls the PR or your uncommitted changes through the GitHub CLI with your own login — no org-wide app installation, no admin approval, no write scopes granted to a third party.
- It applies your repository's review profile and your local skills, so findings match your architecture instead of generic best practices.
- It runs your own test suite locally to verify a fix and shows the live console output, so the review is not a black box.
- Your source is not uploaded to a CodeCrab server and is not retained by one; the model behind the review is your own Claude Code or Cursor setup, so the agreement you already have with that vendor is the one that governs it.
That is what makes it usable in environments where a cloud review bot never clears review — and it is built for the shift-left pass described in the new PR bottleneck and our pre-push review guide. See how the pieces fit in the documentation.
Try it on your next Pull Request
Free Public Beta — runs 100% on your machine. No code leaving your laptop.
Download CodeCrabKEEP READING
How to Review Code with Claude Code: From Generic Prompts to Repo-Aware Reviews
Claude Code can review Pull Requests, but generic prompts miss what matters. Learn how review skills, repository context and a fixed output format turn it into a real reviewer.
AI Can Write Your Code. But Who Reviews It? The New PR Bottleneck
AI made writing code cheap, but reviewing AI-generated code is now the bottleneck. Learn why PR queues grow, why rubber-stamping is risky, and how to review before the Pull Request.
Code review that fits your workflow: local skills and repository-aware agents
CodeCrab combines your existing local review skills with per-repository profiles and specialized agents, so you can review PRs and pre-push changes with the full codebase in context.
PR Code Reviews: how CodeCrab unblocks your team in the AI era
AI writes more code than ever, so review queues are the new bottleneck. Here is how CodeCrab reviews Pull Requests locally, with repo-specific skills and full engineer control.
My PRs — Feedback: turn vague review comments into a clear fix
Generic or unclear feedback on your Pull Request stalls you for days. CodeCrab investigates every comment with full local code context and hands you a ready-to-run fix prompt.
Pre-Push Code Review: catch bugs before the Pull Request even exists
The cheapest bug is the one that never reaches a PR. CodeCrab reviews your local changes with your repo's own profile and skills, so you push higher-quality code the first time.
