Terminal and Git
The real shell in the Terminal pane, background tasks, the Git pane with its review window and graph, and pull requests
Terminal
The Terminal pane is a real shell, the same one you get in a terminal application: your shell, your prompt, your aliases, colours, interactive programs. It takes the full height of the panel.
You can keep several sessions side by side. New terminal opens another one, the tabs are called "Terminal 1", "Terminal 2" and so on, and Close terminal ends one. Closing the pane only hides the sessions, so the scrollback survives.
Every command runs in a shared folder, with your normal environment. If a tool works in your own
terminal but not here, the usual cause is a PATH set up by your shell profile in a way the app does
not see. Check with which <tool> inside this terminal.
Commands the assistant runs
The assistant runs its commands in a shared folder, and the command and its output appear in the conversation. That way you can tell whether the build actually passed rather than taking a summary for it.
Each command is approval-gated, except in Auto, showing the actual command line. "Always allow" binds to one command family, so approving pnpm test once does not approve everything.
A critical command always asks in Normal and Accept edits, even with a matching standing
permission: a force push, reset --hard, rm -rf, anything under sudo, piping a downloaded
script into a shell, publishing a package. The card names the reason and offers no "always allow".
In Auto these run without a card, see What Auto really
means.
Background tasks
A dev server, a watch build, a long test run does not block the conversation. The assistant can start a command in the background right away, and a command that runs longer than 30 seconds moves there by itself. The turn then continues with the output so far, and the row in the conversation says the command is running in the background.
That is how "start the dev server, then fix the error it prints" works as one request: it starts the server, reads its output, finds the error, fixes the file, and reads the output again.
The Background tasks pane lists what keeps running next to the conversation: commands and sub-agents, split into Running and Done. Each entry has Stop, Copy output and, for a sub-agent, Show transcript. Remove finished tidies up the list. When a task ends, the assistant is told and carries on with the result. Restarting the app interrupts running tasks.
The preview also has a small toolbar with the buffered log of the running dev server.
The Git bar
Right above the composer a slim bar shows the state of the workspace: the branch, the number of changed files, and how many commits you are ahead of or behind the remote. If the branch has a pull request and the GitHub CLI gh is set up, the bar also shows its state (Open, Draft, Merged, Closed) and the checks: Checks running, Checks passed or Checks failed. Open in browser takes you to the pull request, and Hide bar hides the bar.
The Git pane
The Git pane is a full working panel, not a status display.
| Area | What you can do |
|---|---|
| Status | Staged, changed and untracked files, each with +N −M |
| Files | Stage, unstage, view the change, open the file, copy the path |
| Commit | Write a message and commit the staged changes |
| Branches | List, switch, create |
| Remotes | List, add, fetch, pull, push |
| Init | Turn a folder into a repository |
Right-click a file row for its actions. View change opens the diff as an overlay over the pane, with a back arrow. A file that was staged and then edited again shows its own half on each row.
The pane refreshes when something changes, not on a timer, so it does not put load on a big repository for nothing.
Reviewing changes
Review all changes in the Git pane's header opens a review window over the whole app: on the left the files under Staged and Changes with their counts and a stage action per row, on the right the diff of the selected file. The arrow keys or j and k move between files. From an open diff, Show large takes you to the same window.
The Git graph
The fork icon in the Git pane's header opens the Git graph as a card over the conversation. Branches and tags sit on the left, the history of all branches in the middle, and the details of the selected commit on the right, with its files and their diff.
A commit's context menu creates a tag, creates a branch, checks out, cherry-picks, reverts, merges, rebases, or resets the branch (soft, mixed or hard). Everything that writes asks first. Pushing is not in the graph's header; it sits in a branch's context menu.
Git through the assistant
The assistant can do all of this too, by running Git commands: reading the history, finding out when a line was introduced, creating a commit, preparing a branch. The two most common cases have their own commands, /commit and /pr, see Commands.
Useful requests that are more than the pane gives you:
- "Which commit introduced this line, and what else did it change?"
- "Commit this in three separate commits, split by topic."
- "What has changed on this branch compared to main, in prose?"
Both a normal commit and a push are approval-gated, except in Auto. A force push and reset --hard always ask separately in Normal and Accept edits.