If you run long sessions, you eventually hit this moment:

You come back after an hour (or the next day) and you can’t answer the simplest question:

What changed?

The transcript is long.

The tool calls are scattered.

And if you’re on a phone, scrolling becomes its own failure mode.

So I stopped trying to “read everything.”

Instead I built a small review loop around diffs and tool timeline.

This guide is that loop.

TL;DR

1. Don’t reread the whole transcript. Start with a “what changed” surface:
   • files modified
   • diffs
   • tool calls
2. If your tool supports it, use a tool timeline that normalizes tool calls across Claude Code/Codex/OpenCode.
3. Use a turn-end loop:
   • skim tool timeline rows
   • jump to diffs
   • decide: keep / revert / split
4. Happier is one option that makes this easier on mobile because the transcript renders tool calls as a dedicated tool chrome (cards or an activity feed), with tap actions that deep-link you into file/diff views.

The problem

The thing you’re trying to avoid is not work.

It’s unbounded review.

If you can’t quickly see “what changed”, you either:

• trust changes you didn’t review
• or you waste time re-deriving context

The review loop needs to be bounded.

What I tried first (and where I bounced off)

• Read the transcript top to bottom: fine for short runs, terrible for long ones.
• Only look at git diff: good, but you miss why the changes happened.
• Ask the model to summarize: helpful, but I still want to see the real diffs.

If you’re new to Happier

If you haven’t seen Happier before: it’s an open-source companion app (mobile/web/desktop) for coding sessions.

In this guide, the relevant part is the UI review loop:

• tool calls render as timeline rows (or tool cards)
• tool timeline rows can be tapped to jump into details
• tool calls can deep-link into diffs/files

Get set up:

• GitHub: https://github.com/happier-dev/happier
• Install/download: https://github.com/happier-dev/happier#how-it-works
• Discord: https://discord.gg/W6Pb8KuHfg

A review loop that works

The 2-minute version (phone)

When I’m on my phone, I don’t try to do “a full review.”

I do a bounded pass:

1. Scan the tool timeline rows.
2. Jump into the one diff that looks highest risk.
3. Decide: keep / revert / ask for a summary.

Then I stop.

The 10-minute version (keyboard)

When I’m back at a keyboard, I do a deeper pass:

1. Review changed files list.
2. Review diffs in chunks.
3. Split changes into commits.
4. Decide what to keep as-is vs redo.

The rest of this guide is how I make both passes predictable.

1) Use the end-of-turn “diff summary” tool (when it appears)

For Claude Code, Codex, and OpenCode sessions, Happier can show a last-turn diff summary tool at the end of a turn.

When it’s present, it’s the highest-signal starting point because it’s already scoped to:

• “what files changed in the last turn”
• “what did the agent actually edit”

My default:

1. Tap the last-turn diff summary.
2. Open the single highest-risk file first.
3. If it looks good, keep going.
4. If it looks weird, stop and ask for a per-file rationale (or revert just that file).

3) Review the last turn from Source Control (the “real diff” surface)

If you want a proper review (not just a quick skim), go to Source Control.

On desktop/wide layouts:

1. Open the session.
2. Open the right sidebar → Source Control.
3. In the changed files list, open the file you care about.
4. Review the diff.

If you find something you want changed but you don’t want to rewrite the instructions in chat, add line-level review comments right on the diff.

Then, when you’re ready to turn comments into action:

• tap the Review comments (N) chip in the composer
• optionally add one sentence of context (“apply these and rerun tests”)
• send

That produces a structured “apply exactly these changes” message instead of a vague back-and-forth.

On phone/narrow layouts, it’s the same flow — it just uses a full-screen view instead of a docked sidebar.

How I keep this “last turn only” instead of “unbounded review”:

• I start from the last-turn diff summary tool, pick 1–3 files, then I review those same files in Source Control.
• If the session has been running for multiple turns, I do not try to review everything that’s currently uncommitted.

4) Use Files as your “scoped navigator” (modified-only filtering)

The Files tab is useful when you want a tight list of what’s dirty without thinking about Git semantics.

1. Open the session.
2. Open right sidebar → Files.
3. Turn on modified-only filtering.
4. Use that narrowed tree to jump between files.

When I’m doing a serious diff review, I still do the final “keep/revert?” decision in Source Control — but Files is a great way to stay oriented.

This gives you a clean review surface that doesn’t require scrolling the transcript.

4) (Optional) Use the tool timeline as the “why did this happen?” index

If you’re still unsure why something changed, the tool timeline is a good secondary surface to answer:

• what commands were run?
• what did installs/tests output?
• what sequence led to the diff?

But it’s optional — the diff summary + Source Control diff should be enough for most reviews.

5) Decide how deep you want tool details (skim vs deep)

I treat tool details like a zoom lens:

• Skim mode: just enough to see “what tools ran” and spot risky steps.
• Deep mode: open one tool call when you need the exact command/output.

The key is: don’t let “tool details” become a second transcript you reread forever.

4) End every long turn with a decision (keep / revert / split)

My end-of-turn review decision is always one of:

• keep everything
• revert one file
• split the changes into 2 commits

The key is that you decide intentionally.

One more decision I use a lot (especially on a phone): leave review comments instead of trying to “fix it live.”

If something is almost right but you want a couple precise changes, it’s often faster to:

1. add a few line-level review comments directly on the diff
2. send them as one structured message via the Review comments (N) chip

That gives the agent a very literal checklist of what to change, anchored to the exact lines you cared about.

5) A simple “what changed?” checklist I reuse

If you only remember one checklist, make it this:

• What files changed?
• Were any config/auth/migrations touched?
• Were any tests run?
• Did dependencies change?
• Is there any generated output that should not be committed?

6) Ask for the right kind of summary (when the diff is too big)

If the diff is too big to review on a phone, I don’t ask for “a summary.”

I ask for a structured review aid:

• “List every file you changed and why, in one sentence each.”
• “Which changes are mechanical vs conceptual?”
• “Which changes could be reverted without breaking the build?”

That makes the next keyboard review much faster.

Troubleshooting

I can’t figure out what changed

• start from the tool timeline
• then jump to diffs
• if diffs aren’t available, ask for a per-file list + rationale

The timeline is noisy

Switch to a skimming mode (compact) and look for:

• edit/write tools
• git tools
• installs

I’m worried I’m missing risky changes

Use a “risk filter” pass:

• migrations
• auth
• package manager files
• CI config

Even if you ignore everything else, review those.

FAQ

Should I review every turn?

Not every turn.

But if a turn produced meaningful file changes, I like to do at least the 2-minute version.

What’s the biggest review mistake?

Letting review become unbounded.

The whole goal of a diff-summary workflow is to make review have a beginning and an end.

Related guides

• How to review and commit AI-generated changes on your phone
• How to review diffs from your phone

A workflow I love: inline review comments → one structured “apply these changes” message

This is a feature I end up using when I’m reviewing on a phone or when I want to be very explicit about exactly what I want changed.

Instead of sending a vague message like “fix the diff,” you can leave line-level review comments directly on diffs/files, then send them to the agent as one structured message.

High-level flow:

1. Enable File review comments in Settings → Features (it’s experimental).
2. Open a diff (from Source Control or any diff view).
3. Add a few review comments on the exact lines you want changed.
4. Tap the Review comments chip in the composer (it shows Review comments (N)), optionally add an extra sentence, then send.

The agent receives a structured “Review comments:” block that includes file paths + line anchors + snippets, which makes it much more likely it will apply changes precisely instead of rewriting unrelated code.

If this feels like “GitHub PR review comments, but inside your session,” that’s basically the point.