diffity: a Mac review app that puts Claude in the diff thread

A review app where the fix comes back into the same thread

The idea is one sentence in the description: a Mac app to review the code written by you or your agent with Claude in the loop. The screenshot shows a diff with a comment thread that Claude has answered. The mechanics are what make it different from a diff viewer. You drag across line numbers or click the plus in the gutter, write a comment, and then click Claude in the toolbar to send the comments over to have them fixed. Clicking Claude again and picking comments starts the other direction, where Claude works through each one, edits the code and replies in the thread, and you review its changes like any other diff. That last clause is the important one, because the point is not that Claude edits, it is that you still review the result in the same interface. It works on uncommitted changes and on the commit you have checked out, including comments that came from a Claude review in the first place.

Claude can also be asked directly, and can review on its own

Two more entry points into the same model. You can type @claude in any comment or reply and Claude answers in the same thread, which is the fastest way to ask a question about a specific line without leaving the diff. And there is a separate review path: you click Claude, open Review, optionally add what to focus on, and its comments land on the diff as it works. The distinction between the two matters in practice. The @claude mention is a conversation, so it is for questions. The Review action is a request for judgement, so it is for a second opinion on a change, and the focus hint is what makes it useful, since an unfocused review of a large diff is a wall of comments you have to read anyway.

The command line opens a repo, a ref or a pull request

The terminal integration is where an agent can hand work to the app, and the command accepts a range of targets:

diffity                                        # uncommitted changes in the current repository
diffity ~/code/app                             # another repository
diffity --ref main                             # everything on this branch since it left main
diffity --ref HEAD~1..HEAD                     # the last commit
diffity https://github.com/owner/repo/pull/42  # check out and review a pull request
diffity src/app.ts                             # a file in the Files tab
diffity -n                                     # in a new window

The ref flag takes anything the in-app ref picker does, namely work, staged, unstaged, a branch or a commit, and the two and three dot range forms. The pull request case has a rule worth knowing: a pull request opens in the current repository if it is a clone of that repo, and otherwise in a clone Diffity already knows, and with neither available Diffity offers to clone it. The command itself is installed once from the app menu, with a menu item that links it into /usr/local/bin and asks for your password if that folder needs it. The README notes that coding agents can run it too, so you can ask Claude Code to open your changes in Diffity before it opens a pull request, which is the loop the whole tool exists to close.

Reviewing a pull request and posting it back to GitHub

The GitHub side is a full round trip rather than a read-only view. You pick a pull request from the branch switcher to check it out, comment as you read, and then use Submit review to post it to GitHub. The review can be submitted as Comment, Approve or Request changes, and GitHub comments sync back into the diff so you can reply to them or resolve them from inside the app rather than switching to the browser. The Files tab extends the same comment capability to code that is not part of the diff, so you can open any file in the repository and comment on its lines, which is how you ask about a helper or a test that a change depends on. The ref picker next to the project name handles the rest of the scope: uncommitted changes, a single commit, a range or a whole branch, and it is searchable, so you can find a commit by message rather than scrolling.

Keyboard first, and a rail of open projects

Navigation is entirely keyboard driven, and the two palettes cover different things. Command P opens any file, and Command K searches commits, comments, pull requests and every action, with the screenshot showing the file palette and the dark theme switch. Command F finds in the whole diff, searching every file including the collapsed ones, and Command G jumps to the next match. Projects are kept in a rail on the left, you open a repository with Command O, and Command 1 through Command 9 takes you back to any of them. That last one is a small design choice that says something about the intended workflow: the assumption is that you keep several repositories open at once and move between them constantly, which is what reviewing code across a couple of projects feels like.

A Tauri shell with a React interface and a lot of plugins

The stack is a Tauri desktop app with a Vite and React front end, and the dependency list tells you what the shell has to do. The Tauri plugins cover the dialog and opener, the process plugin for running things, the updater, and window state, and there is a system fonts plugin, so the app can use your system fonts and remember where your windows were. The React side is React 19 with react-router for routing, react-hotkeys-hook for the keyboard layer, zustand for state and tanstack react-query with react-virtual for data fetching and list rendering, which is the pair you would reach for when a diff can contain thousands of lines and a virtualised list matters. Rendering is handled by shiki for syntax highlighting, react-markdown with remark-gfm for the comment text, and rehype-raw with rehype-sanitize for embedded HTML, and mermaid is a dependency for diagram rendering inside comments. The styling is Tailwind 4 with clsx and tailwind-merge, and dayjs handles dates. The package is private, the version in the manifest is 0.1.0, and pnpm 11.18.0 is the pinned package manager.

Releases are cut by a make target and notarised by CI

The release process is in the Makefile, and it is worth reading because it explains the version numbers you will see. The patch, minor and major targets all call a release script with the target name as an argument, and the script takes the current version and bumps the relevant component, so patch gives x.y.(z+1), minor gives x.(y+1).0 and major gives (x+1).0.0. The comment says the script tags HEAD, which must be origin/main, and pushes the tag, and then a GitHub Actions workflow builds, signs, notarises and publishes the release with auto-update metadata. The notarisation and signing step is the reason the app is signed rather than shipped as an unsigned download, and the auto-update metadata is what the updater plugin consumes. There is a separate test-release target that runs a release test script, so the release path can be exercised before a real tag goes out. The published tags are 0.0.18, 0.0.17 and 0.0.16, all within three days in October 2026.

Editorial conclusion

diffity suits a developer on a Mac who reviews a lot of code, including code written by an agent, and who wants the review conversation and the fix in one place rather than copying a diff into a chat window. It does not suit a team on Linux or Windows, since the app is macOS only, and it does not suit someone who wants an agent-agnostic tool, because the Claude Code integration is the centre of it. Before you rely on it, check that Claude Code is installed and logged in, and note that the release stream is a series of 0.0.x tags from October 2026, so the interface is still moving.

Frequently asked questions

Official sources

1. License: MIT
2. nilbuild/diffity on GitHub
3. Project website
4. README
5. Releases