Reviewing changes

The dock

Open it with Ctrl Shift F or from the transcript header. It splits into two sections on one edge, divided by a handle you can drag:

• The explorer is the project tree. Folders holding an edit carry a count; a changed file carries its status letter.
• The viewer shows whatever you opened. An unchanged file shows its contents; a changed file shows its diff.

Keeping them separate is the point. The tree holds its place while the viewer changes under it, so opening a second file does not lose you the first. Either half can be closed for a full height version of the other. Ctrl F searches inside the file you are reading.

Diffs

Diffs render with additions and removals marked, with a per file summary of how many lines moved each way. The change list comes from git, so it is the same set of files git status would show you on that machine, including changes made in a terminal while the chat was idle.

The dock keeps up with a running turn. After the agent edits, writes or runs a command, and again when the turn finishes, the tree and the change list refresh on their own: new files and folders appear where they belong, deleted ones go, and the folders you expanded stay expanded. There is no need to close and reopen the chat.

In a chat you started or branched a moment ago, the dock can show an error for a few seconds while the machine catches up with the new chat. It asks again on its own and fills in once the chat is there. An error still showing after about half a minute is a real one.

A renamed file is marked renamed and opens on a line naming the file it was renamed from. If only the name changed, the viewer says there are no content changes rather than showing an empty diff.

This works on a phone. Reviewing what an agent did on the train is one of the things Termdeck is actually for.

Browsing the project

The explorer browses the real folder on the real machine, read only. It is confined to the folder the chat was opened in and cannot walk above it, which is enforced on both ends of the connection rather than in the interface.

The root stays put while a chat runs. Agents change directory constantly inside shell commands, and the tree does not follow them around: it stays on the folder the chat was opened in, and folders you expanded stay expanded.

One thing does move it. A chat can put itself into a git worktree, which is a second checkout of the same repository on its own branch. The explorer follows it there, because that is where the work is now, and a Worktree row above the tree names the folder and the branch it is on. That goes for a worktree inside the project and for one in a folder beside it. Those files look almost exactly like your project's and are not the same files, which is the whole reason the row is there.

Images open as pictures rather than as bytes. PNG, JPEG, GIF, WebP, AVIF, BMP and ICO up to 5 MB preview in the dock; click one to open it full screen. It opens fitted to the screen, and Actual size in the corner swaps that for real pixels when you need to read the text in a screenshot, which you can then pan around; tapping the picture does the same thing. Close sits beside it, and on a desktop Esc or a click on the background closes it too. SVG is shown as source, on purpose: it is a document that can carry script, so it is treated as one. Anything over 5 MB says so, names its own size, and asks you to open it on the machine, because the whole file has to cross the connection to be shown at all.

Nothing from your repository is ever rendered as markup. Every file, and every line of every diff, is built as document nodes, so a file that happens to contain HTML is text and stays text.

Checkpoint restore

Claude Code snapshots the files it is about to edit before each turn. Termdeck reads those snapshots and turns them into a row in the transcript at each prompt boundary, showing how many files that turn touched. Its buttons appear when you hover the row or the prompt under it, or reach them with Tab. On a phone or tablet they are always shown.

Only files Claude changes with its own file tools (writing or editing a file) are tracked. A file created, changed or deleted by a shell command, such as echo ... > notes.md, a formatter or a build, is never snapshotted: it is not in the checkpoint's file list, and a restore leaves it exactly as it is. The confirmation lists every file a restore will write; anything missing from that list stays as it is, and git is how you undo it.

Restore files puts every tracked file back to its state before that prompt ran. If a turn produced several separate snapshots, which is what the interactive CLI does, restore takes the earliest backup of each file, so rolling a prompt back genuinely means the state before the prompt rather than a partial undo.

The button asks for confirmation and lists exactly what it will write. If the snapshots for a checkpoint cannot be resolved, it refuses rather than guessing, and says nothing was found.

Branch from here

Next to restore sits Branch from here, which starts a new chat holding the conversation as it stood just before that prompt. The prompt itself is left out, so the next thing you send in the branch takes its place. It only ever writes a new transcript, so it needs no confirmation and cannot lose anything. A checkpoint is usually exactly the point you would want to try a different approach from.

You land in the branch straight away. It is named after its source with (branch) on the end (a branch of a branch counts up: (branch 2)), and its sidebar row starts with a branch mark; hover the mark to see which chat it came from. You can rename it like any chat, and a new name drops the mark. The branch starts on the same permission mode, effort and thinking setting its source had, so a chat on Full access branches into one on Full access. Branching copies the conversation only: your files stay as they are, so restore the checkpoint first if the branch should also start from the files as they were. The checkpoint on a chat's first prompt has nothing before it to branch from; start a new chat instead.

Opening a pull request

When the work is ready, Create PR pushes the branch and opens a pull request using the GitHub CLI on that machine, under your own GitHub identity.

It is a modal with a confirmation step rather than a button that fires as a side effect of a panel being open, because it is an outward facing action. It needs gh installed and authenticated on the machine.

Recap

Open a chat's menu and choose Recap for a factual account of what it did: elapsed time, number of turns, files touched, commands run, and cost. It is derived from the transcript rather than generated by a model, so it is instant, free, and cannot be wrong about which files were edited.

It reads the whole transcript rather than the part currently loaded on screen, so a recap of a three hour chat describes three hours.

A review pass that works

1. Open the dock and read the change list first. The shape of a change usually tells you more than the transcript does.
2. Open anything surprising and read the diff, not the agent's description of the diff.
3. Use Recap if you were away and want the commands it ran.
4. Wrong direction? Restore the checkpoint at the prompt where it went wrong, or branch from there and try a different instruction.
5. Happy? Create the PR from here, or take over in a terminal with claude --resume.