feat: add Claude Code PostToolUse hook for review integration

[lucharo]

Hi @wesm, as we discussed briefly in #151, there's currently no way for the main agent to know that a roborev review is happening in the background.

I had been using the roborev TUI, but I wanted to remove myself from the loop and make the agent aware - something close to a notification system. The Claude Code team hasn't released SDK support for this or a way to tap into their notification system (which seems to work for background tasks), so this is my attempt.

The hook at internal/hooks/claude/roborev-post-commit/hook.sh triggers after git commits, queues a review, and outputs a reminder for the agent to address findings.

A few tricks worth noting:

1. Hooks with exit code 0 don't pass context to the agent (useful for linting, not for our use case here). Exit code 2 passes the hook output to the main context. A bit of a magic number, but it works. (see https://code.claude.com/docs/en/hooks#simple:-exit-code)

2. Hook matchers can't use argument patterns like the permissions system can - Bash(git commit*) doesn't work, only Bash. So the hook fires on every Bash call and exits early (with 0) when it's not a git command. I raised anthropics/claude-code#21540 about this limitation but I don't think it'll be addressed.

3. The pattern matches "git commit" anywhere in the command to catch chained commands like git add && git commit. Tradeoff: occasional false positives from heredocs or string arguments containing "git commit".

4. The hook output is kept lean to avoid polluting the agent's context.

Go code changes are still needed to embed and install it to ~/.claude/hooks/.

Question

How should installation work?

1. New command: roborev hooks install
2. Extend existing: roborev skills install --hooks
3. Something else?

[wesm]

Interesting proposal. I'll have to set this up and see what the ergonomics look like. Personally I don't want finished reviews randomly hijacking my interactive sessions -- if I want to use an interactive session to address, I prefer to use the TUI to paste multiple reviews (with y) into the prompt to have discretion about which reviews are addressed at any given time. Of course now with roborev fix and roborev refine I'm using interactive sessions less and less to address reviews.

So if users want what you are doing, we can give them a way to have it, but I'm unlikely to adopt this workflow myself.

[lucharo]

Thanks for the very quick reply! several questions/thoughts

---

I guess it really depends on developer and especially git workflow. I tend to iterate on an idea and only commit when I am confident something has been achieved and isn't wrong so a review after each commit is rarely noise and in general keeps the main agent from diverging. I guess for users that commit every often that might not work as well.

My workflow was already asking the main agent to spawn a sub-agent and then address the review. So roborev in the way I was using was a much leaner autonomous version of that

---

for your workflow, I still don't understand the y workflow, do you select a few, like in vim (e.g. 5y), then yank those reviews and have the agents address?

---

wow! roborev {refine,fix} are super cool! Have you thought of adding a github action that runs roborev refine when an issue is created? It's amazing, might change how I was currently envisioning using roborev — will keep playing with it!

[wesm]

I tend to iterate on an idea and only commit when I am confident something has been achieved and isn't wrong so a review after each commit is rarely noise and in general keeps the main agent from diverging. I guess for users that commit every often that might not work as well.

I feel very strongly that this is the wrong way to work now and rooted in the old human way of working on something until it's "ready" and then committing. After working on this project for a month, I've concluded that you want other agents looking at the code that is being generated right away, not after you've iterated and it's "done" (because it's not done -- it has lots of bugs!)

for your workflow, I still don't understand the y workflow, do you select a few, like in vim (e.g. 5y), then yank those reviews and have the agents address?

I dunno, the copy pasting seems intuitive to me? here is a screencast of me doing it

trimmed_clip.mov

Have you thought of adding a github action that runs roborev refine when an issue is created? It's amazing, might change how I was currently envisioning using roborev — will keep playing with it!

Yeah starting to think about it! all in good time

[lucharo]

Oh I see! y yanks the whole review I see, I do get what you're saying of the old vs new way of working, in that same way isn't it quite noisy to have agents review every single commit even though a piece of work might not be complete? Like, with roborev do you only address a review every x commits? wouldn't it make sense to address each commit no matter often they are made?

Just to show the workflow in action:

⏺ Bash(git add .github/workflows/automated-release.yml CHANGELOG.md CLAUDE.md tests/test_submission.py
      vertex_cli/submission.py && git commit -m "feat: output console…)
  ⎿  [main 67e2d20] feat: output console URL after submission, fix release workflow skip
      5 files changed, 79 insertions(+), 6 deletions(-)
     ruff.....................................................................Passed
     ty.......................................................................Passed
  ⎿  PostToolUse:Bash hook returned blocking error

⏺ Bash(sleep 25 && roborev show 67e2d20c4965e796da24ac5e3d46561945c258c8)
  ⎿  Review for 67e2d20 (job 49, by claude-code)
     ------------------------------------------------------------
     ## Summary
     … +58 lines (ctrl+o to expand)

⏺ Good catches. Let me fix all three:

---

Also, I guess, just to note, I still commit very often, and 99% of commits are done by claude code, I still have it commit in "logical units of work" though that may as well be outdated.

[wesm]

My codex reviews typically take anywhere from 15s to 5 minutes, so it doesn’t make sense for the agent to stop and wait for review when it could be doing other things while waiting on the review. The asynchronous model is simply more productive in my experience, it sounds like you want a synchronous workflow but I’m quite confident this is slow.

[wesm]

isn't it quite noisy to have agents review every single commit even though a piece of work might not be complete?

In my experience so far (> 3000 reviews processed), this isn't really an issue. If the reviews raise an issue that has already been addressed, the agents ignore it. They always look at the current state of the codebase and so changes that have occurred since the review was run does not appear to affect their performance either

[wesm]

I think the review hooks system in #181 is the way to go and keep the focus on asynchronous reviews. If someone wants their interactive Claude sessions to block and wait for a review, we should document the approach for that in https://github.com/roborev-dev/roborev-docs

[lucharo]

To be honest, I tried to implement an async notification hook where Claude would launch the roborev command to check the latest review in the background but couldn't get it to work — again this improve if Claude code or other agent CLIs better expose their notification system.

---

I was using roborev in the way you suggest and I still find the the stream of reviews to be a bit too much, especially if the agent is not aware of them. I understand that reviews are aware of n-3 reviews/code changes though I wasn't aware initially. I'd still find myself feeding all the reviews after several commits to the main agent.

---

Your workflow sounds fascinating though. I still can't imagine what using agents fully non interactively looks like, I can't trust them to not diverge very quickly and waste a bunch of time after. Also you saying your average review can be up to 5 mins made me reconsider whether I'm not being ambitious enough with my agents tasks (averaging 1-3 mins reviews after serious project use)

---

either way, I don't want to clutter a PR with a discussion! please feel free to close the PR if it doesn't go with the intended use/design philosophy of the project. I'll keep iterating and finding ways the tool fits my workflow, thanks @wesm!

[wesm]

All good, I'm very curious about what works well for different people! I'll investigate how to create some kind of a "review inbox" for Claude since I don't think that blocking the interactive session makes sense as a design. Here are some statistics on runtimes for the reviews in my environment:

⏺ ┌──────────────┬─────────┬───────────┬────────┬─────┬─────┬─────────┐                                                                                                                                  
  │    Agent     │ Reviews │ Completed │ Failed │ Avg │ Min │   Max   │                                                                                                                                  
  ├──────────────┼─────────┼───────────┼────────┼─────┼─────┼─────────┤                                                                                                                                  
  │ codex        │ 2,696   │ 2,661     │ 9      │ 93s │ <1s │ 19m 55s │                                                                                                                                  
  ├──────────────┼─────────┼───────────┼────────┼─────┼─────┼─────────┤                                                                                                                                  
  │ gemini       │ 500     │ 496       │ 1      │ 69s │ <1s │ 9m 53s  │                                                                                                                                  
  ├──────────────┼─────────┼───────────┼────────┼─────┼─────┼─────────┤                                                                                                                                  
  │ claude       │ 479     │ 477       │ 1      │ 14s │ <1s │ 4m 55s  │                                                                                                                                  
  ├──────────────┼─────────┼───────────┼────────┼─────┼─────┼─────────┤                                                                                                                                  
  │ opencode     │ 9       │ 2         │ 7      │ 12s │ <1s │ 1m 46s  │                                                                                                                                  
  ├──────────────┼─────────┼───────────┼────────┼─────┼─────┼─────────┤                                                                                                                                  
  │ ollama       │ 8       │ 0         │ 8      │ <1s │ <1s │ 1s      │                                                                                                                                  
  ├──────────────┼─────────┼───────────┼────────┼─────┼─────┼─────────┤                                                                                                                                  
  │ droid        │ 4       │ 1         │ 3      │ 15s │ 1s  │ 58s     │                                                                                                                                  
  ├──────────────┼─────────┼───────────┼────────┼─────┼─────┼─────────┤                                                                                                                                  
  │ copilot      │ 2       │ 2         │ 0      │ 63s │ 61s │ 64s     │                                                                                                                                  
  ├──────────────┼─────────┼───────────┼────────┼─────┼─────┼─────────┤                                                                                                                                  
  │ gpt-5.1-nano │ 1       │ 1         │ 0      │ 9s  │ 9s  │ 9s      │                                                                                                                                  
  ├──────────────┼─────────┼───────────┼────────┼─────┼─────┼─────────┤                                                                                                                                  
  │ cursor       │ 1       │ 1         │ 0      │ 24s │ 24s │ 24s     │                                                                                                                                  
  └──────────────┴─────────┴───────────┴────────┴─────┴─────┴─────────┘ 

I think some of the longer reviews were scenarios when I was connected to my mobile hotspot or on an airplane, but this should give an idea why the synchronous review concept is problematic

[wesm]

I'd still find myself feeding all the reviews after several commits to the main agent.

FWIW, when I'm not using roborev fix, I'm generally feeding batches of 3-5 reviews to the interactive session through the prompt with the y key like I showed you in the video. For me, this is yielding very good results in terms of finding and fixing issues, and avoiding agent idleness (and as a result I'm hitting my weekly rate limit on Claude at least twice as fast as I was before).