Know where to start.
Related changes are grouped into sections, with a reason to read each one. Follow the connections between files and see which references deserve your attention.
Your workspace for code review.
An agent filters for salience, you inspect what’s important, ask contextual questions, and decide what’s ready to ship.
The more code your team writes,
the more your judgment matters.
Coding agents produce changes faster than your human team can comfortably review them. The human review is the inflection point in any release, and teams who skip it ship slop.
Airlock is the sacred space for that inflection point, and it presents each PR with respect for your time.
- Backfill currency on legacy orders
- Regenerate the payments client
- Add idempotency keys to refunds
- Move the session store behind an interface
- Retry webhook delivery with backoff
- Prevent duplicate charges at checkout
From a sprawling PR to an informed decision.
Open the pull request you need to review.
Paste a GitHub pull request URL, or pick one from your projects. Airlock finds the local repository, or helps you clone it, and fetches the branch. Inspect the commits and files while the agent prepares a reading plan.
Know what to read. And why.
The agent reads the full change and surrounding source, then groups references into ordered sections with a reason to read each. Open the code, pulled directly from git, and mark sections read as you go.
Ask a question. Check the cited code.
Ask the agent about what you are reading; its answers cite files and lines you can inspect. It also checks statements in the PR description against the code. Questions about why the author made a choice stay for the author to answer.
Build your review from what you find.
Save an answer after checking it, write your own note, or add a question for the author. Each goes into your review under its file or section. You can edit or remove it later.
Your review, ready to share.
Edit your saved notes, answers, and author questions together. Preview the finished review, copy it as Markdown, and paste it into GitHub. You choose every entry and when to post it.
- Follow the plan. The agent reads the full change and surrounding source, then groups references into ordered sections with a reason to read each. Open the code, pulled directly from git, and mark sections read as you go.
- Check the evidence. Ask the agent about what you are reading; its answers cite files and lines you can inspect. It also checks statements in the PR description against the code. Questions about why the author made a choice stay for the author to answer.
- Choose what to keep. Save an answer after checking it, write your own note, or add a question for the author. Each goes into your review under its file or section. You can edit or remove it later.
- Export your review. Edit your saved notes, answers, and author questions together. Preview the finished review, copy it as Markdown, and paste it into GitHub. You choose every entry and when to post it.
Or pick one from your projects
Prevent duplicate charges at checkout
- 01The payment requestFollow a checkout from Pay to the payment provider.Read
- 02Duplicate protectionCheck how repeat requests reuse the same payment key.Read
- 03Timeouts & testsInspect the test for a lost payment response.Read
2 of 3 sections read3 of 3 sections read
Move session storage behind an interface
- 01The storage interfaceRead what a session store is now required to do.Read
- 02The Postgres implementationCheck the existing queries against the new methods.Read
- 03Callers and fixturesInspect what the tests substitute for the real store.Read
2 of 3 sections read3 of 3 sections read
Upgrade the payments SDK to v7
- 01What v7 removedRead the calls that no longer exist in the new client.Read
- 02The call sitesCheck each replacement against what it replaced.Read
- 03Webhook signaturesInspect how an incoming webhook is verified now.Read
2 of 3 sections read3 of 3 sections read
“What if payment succeeds but the response never arrives?”
Reading the change…
Evidence to inspect
The retry reuses the original payment key. The timeout test checks that only one charge is created.
payments/charge.ts:41–58payments/charge.test.ts:72–94
“What happens to sessions already in flight when this ships?”
Reading the change…
Evidence to inspect
The Postgres implementation keeps the existing table and column names, so a row written before the deploy still resolves through the new interface.
sessions/store.ts:18–44sessions/postgres.ts:57–90
“Does v7 change how webhook signatures are verified?”
Reading the change…
Evidence to inspect
v7 moves verification onto the client and drops the standalone helper. The call site passes the raw body, which the old helper also required.
payments/webhook.ts:22–51payments/client.ts:14–29
Findings in Duplicate protectionEach one files under the section you read it in
- An answer you checked
After a timeout, retries reuse the original payment key.
Added - A note in your words
Please also test two Pay clicks arriving together.
Added - A question for the author
How long should a customer be able to retry a payment?
Added
Your review is empty3 entries in your review
Findings in The storage interfaceEach one files under the section you read it in
- An answer you checked
The Postgres store keeps the existing table, so sessions in flight survive the deploy.
Added - A note in your words
Worth a test that writes a row in the old shape and reads it through the interface.
Added - A question for the author
Is a second implementation planned, or is the interface here for the tests?
Added
Your review is empty3 entries in your review
Findings in Webhook signaturesEach one files under the section you read it in
- An answer you checked
v7 verifies webhooks on the client, and the raw body is still what gets signed.
Added - A note in your words
The retry backoff takes new defaults in v7 — worth saying so in the description.
Added - A question for the author
Was a compatibility shim considered, or is a diff this size deliberate?
Added
Your review is empty3 entries in your review
Duplicate protection
An answer you checked
After a timeout, retries reuse the original payment key.
A note in your words
Please also test two Pay clicks arriving together.
A question for the author
How long should a customer be able to retry a payment?
payments/charge.ts:41–58payments/charge.test.ts:72–94
Your observations. Your open questions.
The storage interface
An answer you checked
The Postgres store keeps the existing table, so sessions in flight survive the deploy.
A note in your words
Worth a test that writes a row in the old shape and reads it through the interface.
A question for the author
Is a second implementation planned, or is the interface here for the tests?
sessions/store.ts:18–44sessions/postgres.ts:57–90
Your observations. Your open questions.
Webhook signatures
An answer you checked
v7 verifies webhooks on the client, and the raw body is still what gets signed.
A note in your words
The retry backoff takes new defaults in v7 — worth saying so in the description.
A question for the author
Was a compatibility shim considered, or is a diff this size deliberate?
payments/webhook.ts:22–51payments/client.ts:14–29
Your observations. Your open questions.
PR feedback copied to clipboardCouldn’t reach the clipboard
01 / 05 · Open the PR
Inspect the evidence.
Every displayed line of source comes from git. Claims from the PR description are checked against the code, with a verdict and references you can inspect yourself.
Work through your questions.
Ask about a section or the whole change. Follow up, open the cited code, and investigate the answer. Questions about the author’s intentions stay for the author to answer.
Build your review
as you go.
Keep an answer you’ve checked. Write a note in your own words. Add a question for the author.
Airlock brings those choices together under their file or section. Edit your entries, then copy the document as Markdown or send it to the PR as a draft you submit yourself. You choose every entry in the finished review.
Understand what Airlock can access02 · Duplicate protection
payments/charge.ts
After a timeout, retries reuse the original payment key. Please also test two Pay clicks arriving together.
charge.ts:41–58 · charge.test.ts:72–94
How long should a customer be able to retry a payment?
From a PR to
your first review.
You’ll need an Apple Silicon Mac, git, GitHub’s command-line tool (gh), and your own Claude subscription. The guide covers setup and your first review.
Read the getting-started guide- 01
Open the pull request.
Choose a PR from the inbox across your projects or paste its GitHub URL. Airlock finds the checkout and fetches the branch.
- 02
Read, ask, and keep.
Follow the reading plan and open the code. Ask questions and save only the answers, notes, and author questions you want in your review.
- 03
Edit and copy your review.
Edit your collected notes and questions. Copy the review as Markdown, ready for the PR.
Open source stays free.
Your work stays yours.
Free for public repositories. One annual licence for private work.
Public repositories
Free. Without limit.
Open-source and public projects never need a licence. Download Airlock and open your first pull request.
Private repositories
$99 / year
An individual licence. Your first month is free, starting when you open your first private PR. The trial needs no account. Activate your licence by pasting your key into the app.
After your free month, a licence is required to plan new private reviews. Keep full access to your existing sessions, review documents and exports.
How licensing works →Questions before you start.
Requirements, model access, privacy, and licensing.
Does Airlock write my review?
You do the reviewing. An agent plans what to read, in what order, and why. Your review document contains only the notes, answers and questions you explicitly write or keep. Export Markdown, or send it as a draft review on GitHub — you submit it yourself.
What do I need to run it?
macOS on Apple Silicon, git, GitHub’s gh installed and signed in, and a Claude Code login through a claude.ai subscription. The PR must be on GitHub and its branch must be pushed. Intel Macs, Windows and Linux are not supported.
Do I pay Airlock for model usage?
No. Airlock uses your own Claude Code login and never bills for tokens. A Claude subscription is required. Airlock works with Claude Code through your own Claude subscription.
Where does my code go?
Sessions live in SQLite on your Mac. Model calls go to Anthropic through your own Claude login. No code reaches Airlock’s servers. The app also checks airlock.build for updates. Read the code and data details.
Where does the displayed code come from?
Airlock pulls every displayed source line directly from git at the reviewed revision. The agent chooses the file and line references and their reading order; Airlock retrieves the source for you to inspect.
What happens when the author pushes?
Airlock marks affected sections you have read and claims with changed evidence as out of date, naming the files. Files not covered by the plan get a new section at the end. Your existing order stays the same. You choose when to recheck a claim; the new verdict appears beside the original.
How does licensing work?
Public repositories are free without limit. An individual licence for private repositories costs $99/year. Your first month on private repositories is free, starting with the first private PR you open. The trial needs no account. Buy a licence, then paste your key into Airlock.
What happens after my free month?
Every existing session, review document and export stays open. A licence is required to plan new private reviews. Public repositories remain free without limit.
Which Git hosts are supported?
GitHub. Use another host? Tell us which one. Share feedback.
Merge with confidence.
Understand the change. Check what matters.
Make the call.