Source control and history

3 min read

Agents edit real files in a real repository, so the Director keeps the answer to "what did it actually change?" one tab away. The Source Control tab shows the state of the session's git repository - it has two pages, Changes and Worktrees; for the conversation that produced it, the History button and the Cockpit's Chat tab are covered below.

The changes badge

A session card can carry an amber "N chg" badge - a count of uncommitted changes in that session's working tree, staged and unstaged together, so a file staged and then edited again is counted in both. The badge is absent, never "0 chg", when the tree is clean or the count is unknown - absence is not proof of a clean tree. And the number is the last count a probe produced: when a later probe fails or the folder goes missing, the Director keeps that number rather than reporting zero, so it can be stale. It is still the earliest honest signal of progress: an agent that claims to be done with no changes reported, or one that has quietly touched forty files, both deserve a look before you move on.

The Source Control tab

Select a session and open Source Control. A rail down the left side holds the tab's two pages - Changes, which opens first, and Worktrees, which carries a red count when a repository has worktrees you can clear away.

Changes

At the top, the branch bar shows the current branch and how it relates to the rest of the world: a green ^N badge counting commits not yet pushed, an orange vN for commits not yet pulled, a blue badge naming the main branch when yours has fallen behind the main line, and a small "no upstream" note when the branch has no upstream yet. Below it, the Changes file tree lists what the agent has modified, with a count in its header; a second tree, Staged Changes, appears above it only while something is staged. When the working tree is clean it says so: "No changes detected".

Every file in either tree carries one letter for what happened to it: M modified, A added, D deleted, R renamed, C copied, and U untracked - a new file git is not following yet. R and C are drawn in the same blue, so read the letter rather than the colour when it matters which of the two it is.

Right-click a file for View File, Copy Path, Copy Relative Path and Add to .gitignore. The last one is the polite way to silence a generated file that keeps turning up in reviews where it does not belong.

Worktrees

Running several agents at once tends to leave a trail of git worktrees behind, and after a week nobody can remember which ones are finished. The Worktrees page scans the session's repository and sorts every linked worktree into three groups, each with its own count and a plain sentence saying what the group means:

Safe to reap - the work is already on origin/main and the tree is clean, so nothing is lost by removing it.
In use by an open session - the work has landed, but a session is still open in the folder. These are held back until you close it and are never removed while in use.
Needs attention - the worktree carries unmerged commits or uncommitted content, so a person has to decide. Never removed for you.

Remove orphaned worktrees appears only when there is at least one in the safe group, and it shows you exactly what it is about to remove before it acts. Refresh re-scans (it runs a fetch with prune first, so the merged-or-not verdict is current), and Copy report puts the whole listing on your clipboard as text - handy for pasting into an agent and asking it to deal with what needs attention. A repository with no linked worktrees says so.

Note

The repository screen has a worktrees tab of its own, covered on repositories and worktrees. That one is about a repository you are managing; this one is about the repository the selected session is working in.

Note

Line-by-line differences are not on this tab - they are on the repository screen's Changes tab, in repositories and worktrees - and two things behave differently there for an untracked file, both because git has no earlier version of it to compare against. Its difference is its whole content, every line rendered as added under a hunk header ending (new file), which is the reading it deserves: all of it is new, so none of it has been reviewed. And Discard changes does not appear on it at all - that button shows only on a tracked file with unstaged edits, because those are the only changes git can put back. If an untracked file is noise, gitignore it; if it is wrong, delete the file itself.

Note

The Source Control tab is a review surface, not a git client. When you are happy with the changes, commit them the way you always do - ask the agent to commit, or use your own git tools. Open in VS Code and Open in Explorer on the card menu drop you into the repository directly.

Conversation history

The History button on the action bar above the prompt bar opens the agent's own in-terminal history picker - for Claude Code, the same picker its double-Escape opens - so you can jump back through the live conversation right in the terminal. Esc closes it.

For a readable transcript - every message between you and the agent, with Show filters for Tool calls, Results, and Thinking so you can read just the conversation or audit exactly which actions the agent took and what came back - open the session in your browser: that is the Cockpit's Chat tab, on Working in a session.

Tip

When a diff surprises you, read the Cockpit's Chat tab with only Tool calls turned on. The list of file edits and commands, in order, is usually the fastest way to see where the agent went off the path you intended.

Past sessions

The Resume Session tab in the New Session dialog lists past Claude Code conversations - each with a summary, its message count, and how long ago it ran. See starting and steering agents.