Skip to main content
The session panel is the deterministic counterpart to asking an agent to “commit this”. It stages, commits, pushes, and opens pull requests directly — no chat round-trip, no agent deciding whether it ran git correctly. Open it with the ☰ button in the top-right toolbar of a workspace. It shows the live state of the working tree and stays in sync during a run: whenever a file-touching tool finishes, the counts update in place.

​
The Rows

Rows open their form in place, so more than one can be open at a time.

​
Changes

Expand the row to list every changed file with its own +/- counts. Clicking a file opens its diff — the same view the Changes tab shows — rather than the whole current file. The counts include untracked files in full, which a plain git diff HEAD would omit, so the number here matches the one on the workspace item in the sidebar.
Undo asks first, and the confirmation names the real outcome. Reverting a committed file restores it from git. A file that was never committed is deleted — that can’t be undone.

​
Switching Branches

The branch row expands into the project’s branch list (a worktree shares its repo’s refs, so the names are the same either way). Click one to check it out. A clean tree switches immediately. A dirty one asks first — uncommitted work travels with a checkout, or blocks it when the target branch touches the same files. If git refuses, its own message explains why (a common case: the branch is already checked out in another worktree).

​
Commit

A blank message triggers a single headless model call — one shot, off to the side, not a chat turn. It reads the staged diff and your commit instructions and returns a message. The provider and model are the ones selected for the workspace. Committing from a detached HEAD is rejected, and a commit with nothing staged fails rather than creating an empty one.

​
Create Pull Request

The action is deterministic, in this order:
1

Verify the remote

origin must still match the project’s recorded remote. A drifted remote aborts here — before anything is pushed.
2

Resolve the base branch

The workspace’s base branch, falling back to the project’s default branch. A PR from a branch to itself is rejected.
3

Push the head branch

gh pr create needs the branch to exist on the remote.
4

Create the PR

gh pr create runs with an explicit --head, since worktrees often have no upstream tracking for gh to infer.
The created PR opens in your browser and is recorded in the workspace activity log.
Requires the GitHub CLI (gh) installed and authenticated. When gh fails, Mains surfaces its stderr verbatim rather than a generic error.
The action is disabled while you’re on the default branch — there’s nothing to open a PR from.

​
Publish Repository

When a workspace’s repo has no origin remote, push and PR are impossible, so the panel offers Publish repository in their place. It creates the GitHub repo and wires up the remote. A preflight checks that gh is installed and authenticated before the form is usable. Once published, the repo opens in your browser and the push/PR rows take the publish row’s place.

​
Instructions

Generation prompts pick up your writing conventions from two places, project-level first: Examples: “use conventional commits, keep the subject under 72 chars” for commits, “include a test plan and link the related issue” for PRs.

​
Agents Do The Same Thing

The CommitChanges and CreatePR tools available to agents delegate to this same code, so a commit made by an agent and one made from this panel are identical in behavior — same staging rules, same remote check, same activity log entry.