Review code changes

When your working directory is a git repository, you can review exactly what changed right beside your terminals. That's handy when an agent is editing files and you want to watch its work.

Inline diff viewerCopy Anchor Link

The diff viewer is a tile, so it sits alongside your terminals. Open it by double-clicking a repository path printed in terminal output, or by choosing View diff from a path's right-click menu.

The viewer lists every changed file with its status (modified, added, deleted, or renamed) and the count of added and removed lines. Click a file to expand its syntax-highlighted diff. Use j and k to move between files quickly.

For each file you can:

• Copy the path or copy that file's diff to your clipboard.
• Open the file in the preview or editor panel.
• Discard the file's changes to revert it to the last commit.

Across the whole repository, the top bar lets you filter the file list, refresh to reload, copy the full diff as one unified patch, or discard all changes at once.

Revert or copy a hunkCopy Anchor Link

You do not have to accept or reject a whole file. Inside a diff, hover over any line to reveal a small menu. From it you can copy the line, copy the surrounding hunk as a unified diff, or revert just that hunk back to its committed state, so you can keep part of a change and drop the rest.

Per-line historyCopy Anchor Link

To understand why a line looks the way it does, open the diff or file and pull up its history. Each line shows who last changed it and in which commit, and you can step back through earlier versions to see how a block evolved over time.

Blame keeps the code in view in a narrow tile, and Diff on a file with no uncommitted changes says so.

History tells you who and when. If you also want to know why, each commit card in Blame expands to show the agent turn and the request behind that line. See why a line exists.

Edit with language intelligenceCopy Anchor Link

Open a file from the diff viewer or the terminal and it lands in an editor with the language server for that file wired in. A mistake gets an inline squiggle with a hover diagnostic, and completion suggests as you type, so you can fix something the review turned up without leaving the session.

Comment and suggest on codeCopy Anchor Link

Reviewing is not only reading, you can mark up the code in place. Open a file in an editor tile and each person picks a mode: Editing, Suggesting, Commenting, or Viewing. Select a span and leave a comment and it anchors to those lines with a gutter marker, a highlight, and a threaded card in the margin rail you can reply to and resolve. In suggesting mode your edits land as tracked changes the author can accept or reject.

If the host made you a suggester, files open in Suggesting mode and Editing is not offered: you can propose changes and comment, and a writer decides what goes in.

To start a comment, select lines and click the comment button in the gutter, or put the caret on a line and press Cmd+Alt+Shift+M (Ctrl+Alt+Shift+M on Windows and Linux). In a rendered Markdown preview the button sits in the left margin, level with your selection.

In a narrow tile, like a terminal and editor split, the rail collapses each annotation to a single line: a comment shows its author and a snippet, a suggestion shows the insertion or deletion. Click a card to expand just that one.

A comment stays anchored when you switch the same tile to Diff, side by side, or Blame, so a note you left while editing is still there while you review the change or read a line's history.

Agents can annotate too. From a session terminal, taiku func comment and taiku func suggest place a comment or a tracked edit on a file by line or by matched text, and it appears live in the editor tile next to the terminal, so an agent can flag a spot for you to look at.

It works the other way too. Leave comments on a file, then tell the agent to read them:

taiku func list-comments --file src/app.ts --json
taiku func comment --file src/app.ts --reply-to <thread-id> --body "Fixed in the null check"
taiku func resolve-comment <thread-id> --file src/app.ts

list-comments gives each open thread's line range, the text it's attached to and every reply, plus any pending suggestions.

Branch status and pull requestsCopy Anchor Link

The diff viewer's sidebar also shows where your branch stands:

• The current branch name and its upstream.
• How far the branch is ahead (↑) or behind (↓) the remote.
• A warning when the branch has no upstream yet, so nothing has been pushed.

If an open pull request exists for the branch, a #number chip appears. Click it to open the pull request in a browser tile inside your session. The chip shows up when your host is signed in to GitHub; otherwise it stays hidden.

Track what a command changedCopy Anchor Link

You can record the diff that each command produces, which makes it easy to see exactly what a build script or an agent run touched.

In the Activity panel (the bell icon), turn on Track diffs. From then on, every command that finishes shows a Δ N badge, where N is the number of files that command changed. Click the badge to open that command's diff in the viewer, so you review the result of one specific run instead of the whole working tree.

This pairs naturally with agents: leave Track diffs on, let an agent work through a task, then step through each step's changes from the Activity panel.

To start a session with it already on, without opening the panel, run taiku --track-repo-diffs (or set TAIKU_TRACK_REPO_DIFFS=1). It applies to that session only and leaves your saved setting alone, which makes it the way to put tracking on a session you start from a script or hand to someone else.

A session page has to be open somewhere for the diffs to be captured: the flag decides whether tracking is on, and the page is what records each run. Starting a session with the flag and never opening it captures nothing.

Rewind a run with the TimelineCopy Anchor Link

With Track diffs on, taiku keeps a history of every recorded run: each command and each agent step. Open the Timeline from the Activity panel to see them as a list you can move through.

From the Timeline you can:

• Open any run's diff to see exactly what it changed.
• Compare any two runs to see what happened between them.
• Revert a run to undo just that run's changes on your working tree, leaving everything else intact, including edits you made by hand before or after it.
• Reapply a run you previously reverted.

This is the fastest way to undo an agent's changes when it goes down the wrong path: instead of untangling the whole working tree, revert the specific step that introduced the problem and keep the rest. Revert and reapply merge cleanly against your current files, so you can move back and forth without losing work.

Revert and Reapply show what they will change first: every file and the lines in it, and which files have your own edits in the same lines and will get conflict markers. Nothing is written until you confirm.

The history stays on the machine that holds the files, in taiku's own data folder rather than in your repository, and no sandboxed shell is given access to it. Once a folder's runs pass 2 GB, the oldest are dropped first. History recorded by older versions of taiku isn't carried over, so after updating the Timeline starts empty.

The preview comes from the taiku running on the machine that holds the files. If that taiku is too old to show it, Revert says to update taiku on that machine and changes nothing.

Next stepsCopy Anchor Link