Pull requests and issues

Tori reads and writes pull requests and issues on GitHub and GitLab, including GitHub Enterprise and self-managed GitLab. Opening a pull request in the app, the review and merge controls, and starting from an issue need a signed-in account; without one, Open PR opens the host’s compare page in your browser instead.

Open Settings (the gear in the title bar) > Integrations > Hosts.

Click Connect github.com, or Another host… and pick gitlab.com, GitHub Enterprise or GitLab, self-managed.
Sign in:
- github.com uses your GitHub CLI (gh) login when you have one, with nothing to type. Otherwise create a classic personal access token on the page Tori opens, which asks for the repo and workflow scopes, and paste it.
- gitlab.com opens your browser with a short code already on your clipboard. Paste it there, approve, and come back; Tori finishes on its own. Codes last about two minutes. Paste a token instead is there if you prefer.
- GitHub Enterprise and GitLab, self-managed ask for the host’s URL first. A self-managed GitLab can sign in with a token, or with the browser once you give it the ID of an application you created there (with the api scope and Device authorization grant).
The account appears under its host as Signed in, with the scopes the token holds and when it expires.

Each host lists its accounts. You can sign in to several accounts on one host, for example a work and a personal GitHub account; a repository that more than one of them can see shows a person icon on its row to Pick which account this repo uses.

What a card can tell you:

This token expires on 23 Sep 2026. or expired: Sign in again replaces it in place.
Pushes that change GitHub Actions need a newer sign-in. A token without the workflow scope cannot push changes under .github/workflows/. For a gh login, run gh auth refresh -s workflow.
Organisations have not let this account through: an organisation with OAuth restrictions has not approved the sign-in, so its repositories cannot be read. Ask an owner to approve it. Projects affected show a shield on their row.

Remove on an account deletes the token Tori stored for it.

Use the account for git itself

Use for git push and fetch, per host, makes git ask Tori for this account’s credentials when it talks to that host. It covers Tori’s own git, terminal tabs and agents; tabs and agents already open need reopening after you turn it on. Tori has to be running: while it is closed, git asks you as usual.

Use for git everywhere extends the same to git run outside Tori, through your global git config.

When a host has several accounts, choose which one git pushes and fetches as.

The switches

Show pull requests and checks turns the whole integration off or on. Off, Tori stops asking the host for anything, and your sign-ins stay.
Let a chat watch a pull request, off by default, allows watches.

A repository whose host has no account shows a plug icon on its row and in the Changes panel: Add an account for github.com in Settings.

Open a pull request

From the Changes panel, click the Open a pull request button in the header, or from the Pull requests panel when the branch has none.

Tori pushes the branch first if the remote does not have its latest commits.
Open a pull request opens with the Title, the Base branch (prefilled with the repository’s default branch, editable for a stacked branch) and a Description.
Optionally click Ask agent to draft. It asks the selected session to draft a title and body for the branch against the base, measured from where the branch left the base rather than against everything the base gained since. The request lands in its composer; send it, then copy the draft into the form.
Tick Open as a draft if you want a draft pull request.
Click Open pull request. Enter does not submit, so you can write a multi-line description safely.

This in-app form is for github.com with a signed-in account. For other hosts, or without an account, the button pushes and opens the host’s compare page in your browser.

The Pull requests panel

Try it

src/cache.ts+18Viewed

1+import { tokenize } from "./index/tokenize";

3+const TTL_MS = 10 * 60 * 1000;

Bertram Gilfoyle3 hours ago

Ten minutes is a guess. Worth making it a setting?

5+type Entry = { tokens: string[]; at: number };

6+const cache = new Map<string, Entry>();

8+export function cachedTokens(q: string, now = Date.now()): string[] {

9+ const hit = cache.get(q);

10+ if (hit && now - hit.at < TTL_MS) return hit.tokens;

11+ const tokens = tokenize(q);

12+ cache.set(q, { tokens, at: now });

13+ return tokens;

14+}

15+

16+export function sweep(now = Date.now()) {

17+ for (const [q, e] of cache) if (now - e.at >= TTL_MS) cache.delete(q);

18+}

Pull request

openCache query tokens#52

Dinesh Chugtai · opened 3 hours ago

feat/token-cache→main

Files3+33-2

No line comments yet. A summary on its own is a review too.

CommentFeedback without an explicit approvalApproveSign off on these changesRequest changesBlocks the merge until you approve

Write a summary or leave a line comment first.

Dinesh's PR #52 on hooli-search, reviewed from your side. Hover a diff line and press + to leave a comment, tick files as viewed, then submit the batch from the Review tab. The repo needs every check and one approval to merge, so watch the tests finish, approve, and merge from the Merge tab.

The Pull requests panel, in the right panel, is about the branch in front of you: its one pull request.

At the top: the state (draft, open, merged, closed), the title and number, who opened it and when, and the branches. Re-read this pull request refreshes it, Open the description in the editor shows the full description, and the number opens it on the host. When new commits arrive while you are reading, the panel says This pull request has new commits since you read it.

Then three verdict lines: the checks, the review decision, and whether it can merge. Click one to open its tab in the section at the bottom: Review, Conversation, Checks or Merge. Drag the section’s edge to resize it; its height is remembered.

When the branch has no pull request

The panel says which situation it is, with the button for it:

Situation	Button
Commits the remote does not have	Push and open a pull request, or Push only
Pushed, nothing open	Open a pull request
No account for the host	Open compare on github.com, in the browser
You are standing on the base branch	New branch from base

Every pull request in the project

All pull requests, at the top of the panel, lists the project’s open pull requests with their branches. Click one to open it, including one on someone else’s branch that you have not checked out.

Review a pull request

Read the files

The Files tree is shaped like the host’s own review view. Every file and folder has a Viewed box; a folder’s box marks everything under it, and shows a dash when only some of its files are read.

Click a file to open its diff in a tab, with each conversation drawn between the lines it is about and a reply box under it. File diffs share one preview tab, so walking a forty file pull request does not leave forty tabs; a double click keeps one.
Review all files in one tab stacks every file in one scroll, for reading the change in order. The first ten open at once and the rest when you open them.
A binary file says Binary file, nothing to diff, and a very large one Diff too large to load.
Each hunk has Who wrote this hunk. For a pull request opened from a worktree here, it names the agent turn and tool call behind the lines, read at the pull request’s head. A fork’s pull request, or a branch no worktree here holds, says it was written outside any session Tori saw. See Who wrote a hunk.

Keys	Action
`j`, `k`	Next and previous file in the panel
`n`, `p`	Next and previous conversation in a diff
`Cmd+Shift+R`	Open the review form

The letters work only when you are not typing in a field.

Leave comments

Hover a line in a file’s diff and press the + that appears, Comment on that line. Drag across lines first to comment on a range.
Type the comment. It is held, not posted, so you can write several.
To post one right away instead, use Post this comment on its own, now.

Held comments survive a relaunch. Each remembers the exact line it was written against, and the review refuses to post one if that line has moved or now reads differently, or if the branch has new commits, so a comment never lands on the wrong line.

Reply to a conversation

Each thread shows its comments, marked outdated or resolved where that applies. Type in its reply box to answer, and resolve or unresolve it from the thread. A thread’s send button hands it to the session that worked on that branch, for the agent to address; the button names that session and whether it is running.

Submit the review

Open the Review tab (or press Cmd+Shift+R), pick a verdict and write an optional summary:

Verdict	Means
Comment	Feedback without an explicit approval
Approve	Sign off on these changes
Request changes	Blocks the merge until you approve

Submitting posts the summary, the verdict and every held comment together, as one review. A summary alone, with no line comments, is a review too. The review in the panel and the one in the pull request’s own tab are the same review.

Checks

The Checks tab groups checks by outcome, worst first, with the count and colour on each heading. Checks the host skipped get their own group, such as 2 checks skipped, rather than counting as passed, and the verdict line says how many, as in 5 checks passed, 2 skipped. A failing check turns the branch needs you in the sidebar and lights its member chip in a Topic.

Merge

The Merge tab is the only place in Tori that merges. Pick how, Merge commit, Squash and merge or Rebase and merge, and merge. The button is enabled only when the host itself says the pull request can merge, so a rule on the base branch is always respected. Checking whether this can merge… shows while the host decides.

After a merge, Delete branch… offers to remove the branch.

After a pull request is done

The branch keeps its pull request line, with when it merged or closed.
A branch that merged with nothing new since rests on a faint teal wash, and has nothing to push. Commits made after the merge show as commits after merge, for a new pull request.
A closed pull request gets Reopen the pull request where Open PR was. If its remote branch was deleted, Tori pushes it back first, but only when your branch tip is still the pull request’s head and it is not from a fork.
A deleted remote branch reads Deleted in the sidebar, the Changes panel and the graph, rather than looking unpushed.

Start from an issue

Starting a branch or worktree from one of your assigned issues is in the add branch dialog. See Start from an issue. The Autopilot can also pick issues up for you; see Autopilot.

Let a chat watch a pull request

A chat can watch its pull request and be woken when something happens, so you do not have to come back and paste in what a reviewer said.

Turn on Let a chat watch a pull request in Settings > Integrations > Hosts.
Right-click the branch row of an open pull request in the sidebar.
Choose Watch with this session. With several chats open in that worktree the menu names each; with none it says No chat is open in this worktree.

The branch row shows an eye while a chat watches it. Stop watching with this session is in the same menu. An agent can also start a watch itself, through Tori’s MCP server.

The chat is woken with one message from Tori, shown as Tori: news on pull request #482, listing what changed:

a check failed (with a link), or the checks passed,
someone else commented or reviewed, quoted,
the branch now conflicts with its base,
the watch ended, for example because the pull request merged or closed.

A wake only reaches a chat that is idle; news that arrives mid-turn waits for the turn to end. Quoted comments are marked as other people’s words, not instructions, and every wake ends with This is news, not a decision to merge. Ten wakes in a row that bring only comments end the watch, so a chatty bot cannot keep an agent busy forever. Each wake is a turn, and costs what a turn costs.

Close the chat and its news waits for you to open it again. A project’s pull request rule can hand a requested change, a failed check or a conflict to the autopilot instead.