Project settings

Everything Tori keeps for one project lives in that project’s settings dialog. It is drawn like Settings: the project’s icon and name where Settings has its title, a search box and the sections down the left, and a This project card at the foot of the rail with the project’s space, layout and path, and a Copy path button.

Open it

• Right-click a project in the sidebar, or hover it and click its actions button, and choose Project settings.
• Click the broken link mark on a project row, shown when a worktree is missing a shared file. The dialog opens on Worktrees.
• Click the shield mark on a project row, shown when the project is not trusted. The dialog opens on Tooling.
• In Settings > Projects, click a project. The dialog opens over Settings, and closing it lands you back on the list.
• In Settings > Autopilot, under Project contracts, click a project. The dialog opens on Agents, where the contract is.

Escape, the close button or a click outside closes it. While it is open, the project’s row in the sidebar has an accent outline, so you can see where it sits.

Search

The box at the top of the rail searches every section at once, the way Settings’ search does. Each section shows only what matches, under its name, and a group whose title matches shows whole. Click a section in the rail, or press Escape, to clear the search. A second Escape closes the dialog.

What saves when

Changes save as you make them, except three lists that keep a draft until you click their Save: allowed agents, verification commands and issue sources. While a draft differs from what is saved, its section carries a gold dot in the rail, the line beside the buttons says Unsaved changes, and Discard puts the saved list back.

Sections

Which sections a project has depends on its layout:

A bare project whose setup never finished (an empty container) gets the same sections as a bare project.

General

Project shows the Layout, read from disk and not edited here: Git repo, Bare repo with worktrees, Bare repo, no worktrees yet or Folder without git. A Git repo changes to the bare layout with Convert to worktree layout in the project menu. The space, layout and path are in the This project card at the foot of the rail.

Icon sets what the project wears in the sidebar. The card at the top previews it beside a sample sidebar row at the size it is shown, and the strip picks where it comes from:

• Automatic: a favicon Tori found inside the project, so replacing it there replaces it here. With none, a glyph drawn from the folder’s path. Choosing Automatic saves at once.
• Upload: drop an image on the zone or choose a file. SVG, PNG or ICO, up to 2 MB, square works best. The image saves as soon as you choose it, and wins over whatever the project has.
• Pick an icon: search the set and click one. It saves on the click and stays until you change it.

Moving the strip alone changes nothing until you pick something.

Remote, for repos and bare projects:

• Origin, with its URL under it and Set origin or Change origin. Accepts https://, git@ and ssh:// URLs. Existing branches keep their names.
• Default branch: what origin calls its default branch.
• Account, shown when the origin is on a host Tori knows: the account Tori uses for this repo’s pull requests and checks. It is kept per remote, so every project that shares this origin shares it. With no account added for the host, Add an account opens Settings > Hosts. With more than one, pick the one this repo uses.

Worktrees

Bare projects only. What every worktree gets:

• Commands holds the Setup command, whether Agents started over the socket wait for it, the Run command, whether to Open the browser when a server starts (on by default), whether to Start the run command when a worktree is created (off by default) and the Teardown command. Under a command you left empty, each value the repository’s accepted .tori/project.json sets is listed with a repo mark and the worktrees that run it. Typing your own hides them. See A setup command for new worktrees, A run command for each worktree and A teardown command before removal.
• Shared files, with the shared folder’s path and a refresh button in its heading. The list on the left says, for each entry, how many worktrees have it linked, how many are missing it and how many hold a copy of their own, with a warning triangle while anything is missing. Pick one and the right side lists its worktrees, each with a state pill and Link or Unlink, plus Link into N worktrees, Stop sharing and Delete entry for the whole entry. With no worktrees yet, a card says so. See Shared in worktrees.

Agents

Allowed agents limits which agents and accounts may start or resume a session here: Every agent, or Only selected and tick the pairs. The line beside Save counts what is allowed. See Limiting agents per project.

Remembered per worktree is a table of the agent, model, effort and mode a chat last picked in each worktree still on disk, which the next chat in that worktree starts on. A new worktree starts on your defaults. Forget all clears every pick under the project, including ones left by worktrees you have since removed.

Second opinion picks who reviews a session’s work here: A different agent from the session’s, or one agent and account. See Pick the reviewer.

Autopilot contract: while autopilot is on, the heading carries an Autopilot on badge and the project’s contract is here: How work ships, How far it goes, Picking up work, Workers run on, and its Issue sources as one card per source, saved with Save sources. A change made anywhere else, in Settings or by an agent over the socket, shows here at once. While autopilot is off, a card says so and the contract is hidden.

Automations

When your review is requested decides what the project does by itself when a pull request on GitHub asks for your review. It runs every 2 minutes, when Tori checks the host, in any space, with or without the autopilot, and only while Tori is open.

Do:

• Nothing, the default.
• Create a worktree: makes a worktree for the pull request, on its head commit, as soon as it asks for you. Tori never moves it after that. When the pull request’s branch is in the project’s own repo, the worktree and its branch take that branch’s name and track it, so the author’s pushes show on its row as commits to pull, and Pull in the Changes panel brings them in. A push from it goes to the author’s branch. A pull request from a fork has no branch to track, so its worktree is named pr-<number> and stays on the commit it was made at. So is one whose branch name you already have here with work the pull request lacks, or checked out in the repository itself. A worktree you already have on the pull request’s branch is used as it is.
• Create a worktree and review it: the same worktree, and a chat in it that reviews the change against its base. The chat runs in the background, by default in plan mode for Claude, so it reads the change without stopping to ask; another agent runs on its usual mode and may stop to ask you. Runs on changes that. When the author pushes, or asks for your review again, the worktree moves to the new head, but only when nothing in it is yours: no changed files and no commits of your own. Then the same chat is told what changed since it last looked, or a new one starts if that chat is closed. A chat in the middle of a turn finishes it first. A worktree with your work in it stays where it is. The review ends in a verdict and comments for you to read; nothing is posted to the pull request without you.

The rule acts on pull requests that ask for you from the moment you turn it on. Those already waiting stay on the project row’s review requests mark.

Review prompt, with Create a worktree and review it: what the chat is told after the pull request’s number, title, base and head. Left empty, the built-in prompt shown in the field runs.

When a watched pull request needs work hands a pull request a chat watches to the autopilot once that chat is closed. Tick what it acts on: A review requests changes, A check fails, It conflicts with its base. With any ticked, At most per hour (3 by default) caps how many it hands over; past that the rule pauses until you resume it in the Cockpit. It needs Let a chat watch a pull request and Autopilot on, and nothing is pushed without you.

Keep fixing until checks pass lets the autopilot push fixes to its own failing pull requests in this project without asking. Turn on Push fixes without asking; then Attempts (3 by default) caps the pushes per pull request before each asks you again, and Stop when a person reviews or comments (on by default) makes every push ask once someone has. Merging always asks.

Runs on, with Create a worktree and review it: the agent, account, model, effort and permission mode the review chat starts on, picked the same way as in a new chat. Left unset, it starts on the project’s autopilot contract when there is one, else the agent and model a new chat in that worktree would get, in the agent’s read-only mode where it has one. Reset clears every pick. A review chat that is already open keeps what it started on; a pick reaches the next chat the rule starts.

At most per hour, 1 to 50, 5 by default. Past it the rule pauses and a Paused row says so, with Resume. Requests that came in while it was paused are not acted on.

The rule is saved in your own settings, never in the repo, so it never runs on a teammate’s machine. GitLab has no list of review requests, so the rule does nothing there.

With the autopilot on, the rule takes review requests for this project and pickup leaves them to it. With Create a worktree and review it, each review is handed to the autopilot as a running review item, and the autopilot brings you its verdict to approve, the same as a review it started itself. With Create a worktree, the autopilot does not hear about review requests here.

Tooling

Everything about tools that run or check the project’s own code. When the project is not trusted, Tooling in the rail carries a warning dot.

Trust decides whether language servers, debuggers and formatters that run the project’s own code may start. See Project trust.

• Not trusted: a warning card with Trust.
• Trusted, with Revoke.
• Trusted through a folder above the project, when you trusted a parent folder rather than the project. That entry covers every project under it, so it is not revoked from here: Open trusted projects takes you to the list in Settings > Projects.

Repo proposals, shown while a worktree has a .tori/project.json you have not accepted: one row per worktree, saying whether it waits for an answer or you declined it, with Review, and Accept on a declined one.

Commands, for repos: the same commands a bare project has under Worktrees, for the worktrees Tori makes of the repo.

Execution > Sandbox: when this project’s Claude and Codex sessions run in the agent’s own sandbox, As me, Boxed when unattended (the default) or Always boxed. The line under it says what the level does. See When nobody is watching.

Dev servers > Show dev server links: whether servers listening from this project show as links on their worktree’s row and in Scripts. Off by default. See Ports and dev servers.

Dev servers > Ports per worktree: how many ports of each worktree’s block of ten are exported, from 1 to 10. Unset, it is the repository’s accepted count, listed under it with a repo mark, or all ten. Reset clears your own.

Verification commands: the commands that count as a check for the verification badge, one per line. The heading says whether the project uses the Built-in list or its Project’s own list, and the line under the field says what saving will do. Save makes the field the project’s own list. Reset to defaults fills the field with the built-in list, and Save after it goes back to the built-in list. While the project has no list of its own, a list from an accepted .tori/project.json is shown above the field with a repo mark and the worktrees that use it.

Workspace settings, for repos and folders: whether the repo has its own .tori/settings.json, the keys it sets as chips, and Open file, which closes the dialog and opens the file in the editor. The list updates when you save the file. A bare project has one such file per worktree, so it has no Workspace settings here.

Not trusted, in the sidebar

Every project that is not trusted shows a shield mark at the right end of its sidebar row. Hover it for what is off, and click it to open the project’s settings on Tooling, where Trust turns it on.

Settings > Projects

Settings > Projects lists every project Tori found, with its space and whether it is trusted. Clicking a row opens that project’s settings dialog over Settings. Nothing per project is edited in Settings itself.

Below the list, Trusted projects keeps the full trust list, with a search, Revoke and Revoke all. It also holds trusted folders that are not projects Tori found, such as a parent folder you trusted.