Changes panel

The changes panel shows the diff of the active workspace or the uncommitted changes of every project in a column on the right of its panes. It follows the workspace as it changes, so you can watch an agent edit files, review its work as it goes, and point it at a hunk without leaving cornercase.

The changes of an issue worktree, next to the shell that made them.

Open and close it

The panel is there for workspaces inside a git repository. Click Changes at the bottom of the sidebar, next to Issues, to open it, and again (or × in the panel, or Esc) to close it. It shares its column with the files panel, the TODO panel and the Flow panel: opening one closes the others. The button shows how many files changed, such as Changes 3, even while the panel is closed.

The first scope tab follows the active workspace: switch workspaces and it shows the other one’s changes. Its label is the project’s name, with the workspace after › when the project has several workspaces. Drag its left border to make it wider or narrower; a double click on the border gives it back its automatic width, half of the room right of the columns. Whether it is open, its scope and mode, and its width are kept in the saved session.

In the compact layout, a ± button in the top bar opens the panel over the whole screen.

Every project

Click Every project beside the project’s tab to see staged and unstaged edits and untracked files across your open workspaces. Workspaces being removed, clean projects and folders outside git are left out. A header names each project with its file and line counts; when several of its workspaces have changes, their branch or label appears underneath.

Review changes across projects without switching your active workspace.

Files start collapsed. Click a file to load and expand its diff in place; click a project or workspace header to hide or reveal its files. The path filter, viewed marks, collapse all, scrolling and hunk actions work across the collection. open creates a tab in the file’s workspace, and ask agent sends its reference to that workspace’s agent. Both actions show the owning project, workspace and destination tab, so you can use the editor or type your question immediately; the panel stays on Every project.

This scope shows only uncommitted changes, so it has no mode tabs or base selector. Return to the project’s tab to see its commits or choose a base. The Changes n button still counts only the active workspace’s files, and it and ± remain available only in git workspaces.

What it compares

In the project’s scope, three mode tabs choose what you see:

Tab	Shows
Uncommitted	What isn’t in a commit yet: staged and unstaged edits, and new files git doesn’t track yet.
Commits	What the branch committed since it left the base branch.
All	Both: everything the branch changed, committed or not, which is what its pull request will show.

Commits and All compare with a base branch, shown at the right of the summary as vs origin/main ▾. It is the repository’s default branch: the one origin/HEAD points to, or else a local main or master. The comparison starts where your branch left the base, like a pull request on GitHub, so commits that land on the base later don’t show up as changes of yours.

Click vs origin/main ▾ to compare with another branch, local or remote. Type to filter the list, and click a branch or press Enter:

The branch you pick is remembered for that workspace. Picking the default branch again goes back to following the default.

Reading a diff

The summary line counts the files and the lines added and removed, with a bar for the proportion.
Each file has a row with its status (M modified, A added, D deleted, R renamed), its path and its counts. Click it to expand or collapse it.
Each hunk starts with a thin line naming the function or block it is in. Lines carry their old and new numbers, a green or red bar, and a stronger colour on the words that changed when a line was edited rather than replaced.
Code is highlighted with your terminal’s palette.
Between two hunks, ↕ 12 unchanged lines shows the code in between when you click it.
Lockfiles (Cargo.lock, package-lock.json, pnpm-lock.yaml and the like) start collapsed. Binary files and files with more than 3,000 added and removed lines show their counts but no lines in either scope. Every project leaves their patches unread.
When a diff is long, every file starts collapsed. expand all at the bottom expands them all, and collapse all collapses them again.

Filter the files

Click ⌕ next to the panel’s × to show only some files. A field opens under the tabs, and what you type goes to it instead of your pane:

Type	Shows
`order`	Files whose path contains `order`, such as `src/order.rs` or `src/orders/list.ts`.
`*.test.js`	Only the test files.
`src/api/**`	Only the files under `src/api`.
`.ts .rs`	TypeScript and Rust files: every word adds files.
`!.snap !.lock`	Every file but snapshots and lockfiles.
`src/ !*.test.js`	What is under `src/`, without its tests.

A word without * or ? is a piece of the path. With them it is a pattern, as in .gitignore: without / it matches a file or folder name anywhere (*.test.js finds src/cart/total.test.js), with / it matches from the root of the workspace, * stays within a folder, ** crosses folders, and a pattern ending in / matches only folders.
A word that starts with ! leaves the files it matches out.
Case is ignored unless the word has an uppercase letter. A renamed file matches by its old path too.
The summary counts what is left, such as 3 of 31 files.
Enter keeps the filter and gives the keys back to your pane. Esc or the field’s × closes it and shows every file again; Esc on an empty field closes the panel.

Clicking in a pane also gives it the keys back and keeps the filter; a click on the field takes them again. The filter stays when you switch tabs or workspaces, and isn’t saved with the session.

Mark files as viewed

Hover a file row and click the ✓ at its right to mark it as viewed: it collapses, and the footer counts how many you have viewed. When the file changes again, for example because the agent touched it, the mark goes away and it opens again, so you only review what is new.

Act on a hunk

Hover a hunk and three buttons appear on its first line:

Button	Does
open	Opens the file in a new tab, at the hunk’s first changed line, with your `$VISUAL` or `$EDITOR` (or `vi`). The tab closes when you quit the editor.
ask agent	Types a reference such as `src/returns/address.rs:9-10` into the agent running in this workspace and switches to its tab, so you can write your question after it. Without an agent in the workspace, it copies the reference to your clipboard instead.
copy	Copies the hunk, as a patch, to your clipboard.

The editor gets the line as +11, which vi, vim, nvim, nano, emacs and micro understand.

Live, and light on your repository

In the project scope, while the panel is open it asks git for changes every second, so edits show up shortly after they are saved; while it is closed it checks every three seconds, for the count on the button. It runs git in the background with options that never take git’s index lock, so it doesn’t get in the way of an agent running git add or git commit at the same time. When nothing changed, the diff is reused.

While Every project is shown, one background job visits the workspaces in turn, no more often than every three seconds per workspace. Collapsed files need only status and line counts; patches are read and refreshed for expanded files. Closing the panel or returning to the project scope stops that sweep. If a git job takes more than 30 seconds, refreshing can continue with another job.

From scripts and other apps

The same data is there for programs: cornercase changes list prints a workspace’s changed files (--every for every project, --follow to keep printing them as they change), changes file a file’s diff, changes base the branches to compare with and changes viewed marks a file. A program that draws its own changes panel reads them over the socket, as Follow a workspace’s changes describes.