Local code review with AI agents, without opening a pull request

I use Claude Code and Codex quite a lot, which means I regularly have to review substantial changes they make to a project. A successful build and passing tests are reassuring, but they don’t tell me whether I actually like the implementation.

I wanted the familiar GitHub or GitLab review interface for this. The idea was to compare my branch with dev, browse the files, leave comments on specific lines, and send the feedback back to the agent, all before creating a pull or merge request. I’d rather work through the questionable bits myself before asking colleagues to review them.

I also don’t want to hand the whole review to another agent. The article Nobody Reviews Their Agent’s Code makes the same point and describes crit. A human leaves comments on the agent’s changes, the agent fixes them, and the human reviews again. I’m with the author here. AI review can be an extra check, while I’d rather read the changes myself.

Why Xcode and git diff aren’t enough

I build iOS apps and rarely open Xcode unless I have to. Building and testing through MCP is simpler, and there’s less hassle with packages being rebuilt while Xcode is open. So its built-in diff view isn’t really an option for review.

Terminal git diff has a similar limitation. I can read the changes, but leaving a set of precise comments and passing them back to the agent takes extra work.

Say Codex adds a validation check that’s already performed inside CheckoutService. I’d like to select those lines and write “The service already checks this. Why do we need another guard here?”

Then I open CheckoutView.swift and find a new component even though MyAppUI already has one that fits. That’s another comment, and then I carry on reading.

On GitHub I’d put both comments directly in the diff. Locally, I end up switching between the IDE and the agent chat, or keeping a separate list of file paths and line numbers.

I wanted that same pull-request review experience on my own machine. Fortunately, there are tools for it.

The tools I looked at

The first one that caught my attention was difit. It’s a small open-source tool that shows a local Git diff in the browser, with a file tree, syntax highlighting, and inline comments.

For example, to compare the current branch against dev.

npx difit @ dev --merge-base

My favourite feature is Copy All Prompt. I can read through the files, leave comments as I go, then copy the feedback with its file paths and line numbers in one click.

The exported text looks roughly like this.

CheckoutViewModel.swift:L84-L88
Why is this validation repeated here?
CheckoutService already handles this case.

CheckoutView.swift:L42
Use the existing component from MyAppUI.

I paste it into Claude Code or Codex and ask the agent to work through the comments. No need to explain where each issue is.

Later I found an article by difit’s author. The motivation was familiar. Reviewing a long diff in a terminal is uncomfortable, and opening a pull request just to review your own changes is unnecessary overhead. In the author’s workflow, the agent finishes its task, the developer reviews the diff in a browser, and the comments go back to the agent.

That was close to what I’d been looking for. The missing piece, for me, was keeping the agent’s replies alongside the comments so I could revisit the reasoning during the next pass.

Next I tried Plannotator. It integrates with Claude Code and Codex and can send browser feedback to an agent without the copy-and-paste step.

It’s a good idea, but when I tested it with Codex, submitting feedback opened a new session. That may have been down to how I launched it, but I didn’t want that behaviour.

I also switch between agents quite often. If I hit my Codex limits, I might continue in Claude Code. Sometimes I just want a second approach. So I don’t want review history tied to a particular AI session. Codex should be able to handle some comments and Claude Code should be able to pick up where it left off.

I also looked at diffx. It has a browser diff viewer, inline comments, and a local API that lets agents read feedback and post replies. Comments can be resolved, and the sidebar shows which ones are open, replied to, or resolved.

It comes closer to the workflow I want. In the version I looked at, though, comments were kept in server memory. I want the history to survive a restart. And even after an agent has fixed something, I prefer to close the thread myself once I’ve checked the change.

Each tool solves a good part of the problem, but none quite fits how I want to work.

Why I gave up on a live chat

At first I imagined something close to a local GitLab. I leave a comment in the browser, and the agent sees it immediately and replies underneath. I ask a follow-up, and it replies again. The whole discussion updates live.

Once I thought through the implementation, it seemed less appealing. Running a local server isn’t the hard part. You also need to deliver incoming comments to an active Codex or Claude Code session, handle responses, and keep the thread state in sync.

What happens when I switch agents? Which one receives the next comment? Should it interrupt its current task every time I type another question?

There’s also the extra interaction with the model. Reacting to each comment individually can mean more requests and repeated context loading. Batching isn’t necessarily cheaper every time, but it can avoid a lot of unnecessary back-and-forth.

More importantly, I don’t need instant replies while reviewing code. I’d rather finish reading the diff, leave everything I want to say, and hand the comments to the agent in one pass.

So I’m leaning towards an iterative workflow.

1. The agent finishes its task. I open the local diff and leave comments.
2. I send the batch to Codex or Claude Code with one command.
3. The agent answers questions, makes changes, and records its replies.
4. I refresh the diff, check the fixes, and run another review pass if needed.

If a decision is still debatable, I can reopen the discussion next time. I don’t need a permanently connected chat for that.

This is also close to how crit, mentioned earlier, handles review rounds. Comments survive between passes, and the developer checks the code again after the agent makes changes.

It’s a more useful trade-off for me than building another AI chat interface.

Forking a tool as an option

In the end the requirements are simple. I need a local browser diff against a base branch, line comments, a one-step handoff to the agent, and a history that survives between iterations and isn’t tied to a Codex or Claude Code session. I close threads myself once I’ve checked the fix.

It’s simpler to fork a tool and extend it myself than to open a pull request and wait six months. Besides, the author may have a slightly different vision for the tool. I like tailoring tools to myself, and with Codex and Claude Code a small change doesn’t take long. So one option is to take diffx as a base. Also, these are all third-party tools, and with my own fork it is easier to keep track of what actually happens. The version is pinned, the dependencies are known, and there is nothing extra.

Conclusions

I’ve settled on review rounds rather than a live conversation with an agent. Open the diff, leave comments, hand them over, inspect the fixes, and repeat if needed.

I still want to review the code myself. AI can help spot errors and address feedback, but I don’t want to accept its work without understanding the changes.

Of the tools I looked at, diffx is closest to what I need, so that’s the one that can be extended. The goal is small. I want a comfortable local review before opening a merge request, without manually shuttling comments between tools.

---

Links

• difit, local browser diff with inline comments.
• Plannotator, plan and code review integrated with AI agents.
• diffx, local diff viewer with a comment and reply API.
• Difit’s author on local code review, reviewing changes without a pull request.
• Nobody Reviews Their Agent’s Code, human review of AI-generated code and crit.