Repo Terminal

The Repo Terminal is a dedicated terminal session that runs in your repository’s main checkout directory — outside any workspace worktree. It’s available for repositories using the Trunk workflow and gives you a stable place to manage your repository while workspaces come and go.

Why it exists

Workbench uses a trunk workflow where you check out a repository with main locally, then create workspaces (git worktrees) on feature branches. When work is done, you squash-merge the branch back into your local main. This keeps merging fast and local — code doesn’t hit GitHub until you explicitly push, so you can iterate freely without polluting the remote with half-finished branches.

The problem: every workspace terminal runs inside its worktree, scoped to that branch. But trunk-workflow operations — pushing main to the remote, pulling new commits, running repo-wide builds, managing tags — need to happen in the main checkout, not in any individual workspace.

The Repo Terminal solves this by giving you a terminal that’s always rooted in the repository’s main directory, independent of which workspace is selected.

Opening the Repo Terminal

In the sidebar, each trunk-workflow repository has a terminal icon on its header row. Click it to open the Repo Terminal. If one already exists for that repository, clicking the icon focuses the existing session instead of creating a new one — there’s always exactly one Repo Terminal per repository.

When the Repo Terminal is selected:

The terminal fills the main panel (no chat, diff, or file editor)
The terminal cannot be toggled off — it’s always visible
Split view is disabled

What to use it for

The Repo Terminal is the right place for operations that affect the whole repository rather than a single workspace:

Push main to remote — after squash-merging several workspaces, push your local main to share the work
Pull from remote — fetch and fast-forward main to pick up teammates’ changes
Interactive rebase — clean up history before pushing
Tag management — create and push release tags
Repo-wide builds and tests — run the full test suite against main
Manual merges — resolve complex conflicts that automated shipping can’t handle

The trunk workflow in practice

A typical session looks like this:

Add a repository to Workbench with main checked out locally
Set the workflow to Trunk (per-repo in Settings > Repository, or globally in Settings > Git)
Create workspaces — each one branches off your local main into an isolated worktree
Work in workspaces — agents make changes, you review diffs, iterate
Ship — when a workspace is ready, the Ship button squash-merges it back to main and archives the workspace
Open the Repo Terminal — push main to the remote when you’re ready to share

This pattern keeps your remote clean. Teammates see polished, squash-merged commits on main rather than a stream of work-in-progress branches. And because everything merges locally first, you catch conflicts early — before they become PR review surprises.

Lifecycle

The Repo Terminal workspace is created on first click and persists across workspace switches. It’s automatically removed when you close its last terminal tab. It doesn’t appear in the normal workspace list — it lives on the repository row in the sidebar.

Repo Terminal workspaces are excluded from workspace cleanup, SCM polling, and context extraction. They can’t be shared via collaboration since they have no agent or chat context.

Remote access (owner mode)

When connected to a headless server with an owner credential (see Remote Workspaces), trunk-workflow repositories on the remote machine show the same Repo Terminal row. Clicking it opens a live shell on the server, rooted in the repository’s main checkout — the place to run git merge, push main, or anything else that belongs in the main directory while you’re away from the machine. The remote Repo Terminal workspace persists on the server rather than auto-deleting when the pane closes. Workspace-scoped collaboration shares don’t get repo terminals — they’re an owner-only surface.