Most agent tools give you a commit box. Warpforge gives you the git surface you’d expect from an IDE — because when several agents are working in parallel branches, “commit and push” is the least of what you need.
The branch tree
Local and remote branches in one tree, the way a JetBrains or VS Code branch switcher works. Branch names are action triggers, not implicit checkouts — clicking one opens its actions rather than silently changing your working copy.
Actions open in a submenu beside the branch row instead of pushing the list around, so you never lose your place in a long branch list.
What you can do to a branch
| Action | Notes |
|---|---|
| Checkout | Local branches, and remote branches as a new local one |
| New Branch… | From the current branch, checked out after creation |
| New Branch from… | From any specific branch in the tree |
| Rebase onto | Rebases the selected branch onto a target without checking it out first — the same Rebase '<branch>' onto '<target>' behaviour a JetBrains IDE gives you, and your working tree is restored afterwards |
| Merge | Including merging a remote ref into the current branch |
| Pull | With rebase or with merge — your choice, on the menu |
| Rename | |
| Delete | Force-deletes, so an unmerged local branch doesn’t fail with “not fully merged”. The dialog already warns it’s irreversible |
Creating a branch whose name already exists on a remote highlights the collision and requires an explicit Override existing branch before it will proceed — no accidental clobbering.
Native context menus
The git surfaces and the file tree use real OS context menus, not HTML popovers. Right-click a branch, a changed file, or a file in the tree and you get the menu the platform draws, with the behaviour you already have muscle memory for.
In Project Files that includes real filesystem actions — New File, New Folder, Rename, Delete — all daemon-backed, with the tree refreshing after each and deletes requiring explicit confirmation.
Committing
- The message is drafted from the diff in Conventional Commits form — see Text you don’t have to write.
- Amend prefills what you’re rewriting. Tick amend and the box fills with the commit’s existing message, ready to edit or leave alone — the common case being “I just forgot a file.” Anything you’d already typed is kept.
- Stage by file or by hunk, with tri-state checkboxes across the tree.
- Rollback discards selected changes, with confirmation.
When a commit fails
A rejected pre-commit hook arrives as a notification with the reason, not as a wall of text wedged under the commit box — and long output comes with a Copy button for the full log.
If an agent turns down a request (drafting a commit message, say), the message includes the reason the agent gave, which is usually enough to tell a wrong model from a real problem.
Push and pull requests
Push uses --force-with-lease — the safe force, which refuses if someone else pushed since you last fetched.
Open pull request goes through the GitHub CLI with a title and body drafted from the branch’s outgoing commits and their combined diff. It needs gh installed and authenticated; commit and push don’t.
Once a worktree task’s branch has a pull request, the task says so. Its sidebar row carries the pull request’s state — open, draft, merged or closed — with a dot when checks are failing or still running, and the task header shows the number, the state and the checks; click it to open the pull request on GitHub. The status refreshes when you open the task or come back to the window, and every few minutes while the pull request is open. When it merges, Archive and remove worktree (in the header, or the row’s More menu) moves the task to history and deletes its worktree and its task branch, after asking; the conversation stays. It refuses while the agent is working, while the worktree has uncommitted changes, and while it holds commits that are neither pushed nor in the pull request — a squash merge, or a head branch GitHub deleted, does not count against you. A branch you picked yourself when creating the task is never deleted, only its checkout. Without gh, or for a repository that is not on GitHub, nothing is shown.
When the pull request comes back
CI results and review comments land on GitHub, but the agent that opened the pull request is still sitting in its task. So when a check fails or a reviewer leaves a comment nobody has resolved, the task moves to Needs you and a notice above its conversation says what arrived — for example PR #12: 2 checks failed · 3 new comments.
Send to agent hands all of it to that agent as one message, in the same conversation: each failing check with its link and the command that prints the end of its log, then each comment with its file and line, the lines it points at, who wrote it and what it says. If the agent is busy, the message waits for its turn to end. Dismiss clears the notice without sending anything.
For a workflow pipeline that has finished, the feedback goes to the last stage that changed the code — the implement stage or its latest fix — and the notice names it. That agent picks up in its own conversation, and the pipeline does not review the result again. While a pipeline is still running, the button stays off; open the stage you want to reach instead.
Anyone who can comment on the pull request writes part of that message, so everything that came from GitHub — check names, comments, author names, quoted code — arrives marked as untrusted data, with an instruction to weigh it as a report and never run a command found inside it. The log commands are the exception: Warpforge builds those itself, from the job’s number, only for GitHub Actions links. The same marking applies when Address review comments or Work on this branch starts a task from the Inbox.
Either way, what the notice showed is not raised again. A check that fails again after a new push is, and so is a reviewer’s reply in a thread you already sent — your own replies don’t count. Comments count when they sit on a line and are unresolved, or when a reviewer’s latest review requests changes; general conversation comments are left out. Nothing reaches the agent until you press the button.
A task that started from an existing branch or a pull request pushes back to that branch, so the push updates the pull request; for a fork’s pull request the push goes to the fork.
Everything runs where the diff is
A task can run in its own worktree. When it does, every git operation — commit, update, switch, branch, rebase, merge, rollback — and every file operation runs against that worktree, not the project root.
That sounds like an implementation detail. It isn’t: it’s the difference between “the diff I reviewed is the diff I committed” and a class of bug where changes land in a checkout you weren’t looking at.
One merge is the exception: Merge into <base> on the task’s branch menu is about the base branch, not the worktree. It fast-forwards or writes a merge commit on the base and never changes your own checkout unless the base branch is the one checked out there — and then only if that checkout is clean. See Isolated worktrees.
See also
- Working in a task — review, editing, and the rest of the in-task surface
- Tasks and backlog — worktrees and the task lifecycle