Settings

Settings live on two levels: the workspace and the project. The rule is simple: the workspace holds what is common to all projects, the project holds what belongs to one product.

Roles in a workspace

A workspace role and a project role are different things. A workspace administrator has full access to every project, even one where they are not listed as a member. The reverse does not hold: a project manager does not run the workspace.

Workspace settings

• People: invitations, roles, removal.
• GitHub: installing the app and the list of repositories it can reach. Once per workspace, see GitHub.
• Trust profiles: what agents may do, see Security.
• Roles: which assignee roles exist at all: developer, sysadmin, designer.
• Logo: the workspace picture in the workspace list instead of the first letter of its name. PNG, JPEG, WebP or GIF up to 2 MB, square works best. The owner and admins can change it in Settings → Workspace logo.

Personal settings

Your own settings are in the account menu at the bottom of the sidebar, under Profile. They are yours and don't depend on the workspace you are in right now. There are three tabs:

• Profile: name and photo, email, language, time zone, sign-in methods and where you're signed in.
• Notifications: what reaches you and where, the daily summary and quiet hours.
• Appearance: the theme (light, dark or matching the system) and the interface language. The theme is saved in the browser, so your phone can use a different one. Animations follow the system Reduce motion setting: turn it on on your device and the interface stops moving.

A new project

Besides the name and how changes land, the create window has Start from:

• Blank: just the board.
• Template: a website, a mobile app or an internal tool. You get a spec skeleton with sections (goal, audience, pages or screens, tech stack, rules for agents, out of scope) and milestones along the way, such as Prototype → MVP → Launch. Hints in the spec are in italics: replace them with your own text, since agents read the spec before every task. Milestones you typed in the window win over the template's.
• Import: task import opens right after the project is created.

Project settings

The table below is assembled from the settings schema itself: both the list and the defaults are the ones a project gets when nobody touches the setting. It cannot drift away from the system.

Setting	Default	What it does
Accept automatically	off	Accept the result without a human. Off by default, deliberately.
Require passing tests	on	Hold a task out of review until the agent reports its tests passed.
Require green GitHub checks	off	Refuse acceptance while GitHub checks on the pull request's latest commit are not green. This applies to acceptance by a human only: auto-acceptance on merge means GitHub already allowed the merge.
Send the task back when GitHub checks fail	off	A delivered task sits in review and the checks on its pull request's head completed as failures. The platform takes it off review itself and returns it to the agent, naming what failed. It spends an attempt: on the third return the task goes to "Failed".
Task budget, tokens	not set	How many live tokens (input + output) a task may cost before the platform says so. A warning, not a ceiling: work continues, while the managers get a notification and the card gets a mark. Empty means no budget.
Monthly budget, tokens	not set	How many live tokens the project may spend in a calendar month (UTC). On its own, a warning: on the costs page and as a notification to managers at 80% and 100%. Empty means no budget.
Monthly budget in money	not set	How much money the project may spend in a calendar month (UTC), in the currency of the workspace rates. Only agents paid per token count, and only models with a rate. Has no effect without rates. Empty means no budget.
Pause agents at the monthly limit	off	At the monthly limit agents finish the tasks they started, and new tasks in the project wait for the next month or a higher limit. Off by default.
Create a review task when a pull request opens	off	When a pull request opens, a "Review …" task appears on the board with a link to it.
Role for the review task	not set	Empty means the review task is created without a role and is visible to the whole project team.
Slack channel	not set	Where project events go: a task is picked up, finished, an agent asked, something waits for approval. Empty means the project runs on direct messages, a supported mode, not a fault.
Slack channel name	not set	The channel name at the time it was chosen, for display only. The identifier is the truth: channels can be renamed.
Hold new tasks from an agent at 90% of its limit	on	Once 90% of an agent’s 5-hour subscription window is used, new tasks go to other agents while it finishes the current one. The hold lifts on its own when the window resets. On by default.
Tasks per agent at once	1	How many tasks one agent may hold at the same time.
Task lease, seconds	120	How long a lease survives without a sign of life from the agent. Once it expires, the task returns to the queue.
Task timeout, minutes	90	How long a task may stay in progress before it counts as stuck.
Reset agent context after N tasks	8	After how many tasks the agent starts from a clean context.
Branch name template	task/{key}-{slug}	The task key and a slug of its title are substituted in. At most one {key} and one {slug}, with an ordinary character between them, up to 120 characters. A template that breaks the rule is not saved.
Commit message template	{key}: {title}	The task key and title are substituted in.

Listed separately, because these are not "a setting with a value" but screens of their own:

• Members: who works in the project, and in which role.
• Repository: picked from the list of repositories connected to the workspace.
• Trust profile: which of the workspace's profiles applies here.
• Board: columns, saved filters, task templates.
• Notifications: which channels are enabled for the project.
• Logo: the project picture in the sidebar, the project switcher and on the Projects page instead of the key. Same formats and size as the workspace logo. Without a logo the key stays there.

Who may do what in a project

Permissions follow from the workspace role and the project role:

• Viewing a project's tasks is open to any member of it.
• Editing tasks: a member with the matching permission; a workspace administrator and owner always.
• Accepting and returning work is a separate permission, held by the project manager, a workspace administrator and the owner. That is deliberate: acceptance is not the same thing as editing. A member without it can edit a task but cannot accept it or send it back, whether in the task, in Approvals, by dragging a card on the board or in a bulk edit of the list.
• Documents: any member of the project reads and edits them. Only the project manager, a workspace administrator and the owner delete them.
• Assigning project roles: the project manager, a workspace administrator and the owner. A member without that permission cannot give roles to themselves. Taking a role away also affects the person's agents, see Agents.
• Changing project settings: the project manager, a workspace administrator and the owner.

Removing a member

A member can be removed from a project or from the workspace as long as no task depends on them alone. The platform refuses when there is a task that is Queued, Assigned, In progress or Waiting for a human (or holds a lease), is assigned only to this person and has no role: after the removal the dispatcher would find nobody to give it to. The refusal names the tasks, the first five and the number of the rest. Give them a role or another assignee (or move them back to Ready) and remove the member again.

The platform will not move such tasks by itself: there is no safe transition out of the working statuses, and Failed or Cancelled would throw away the agent's work.

Deletion and the bin

Deleted tasks and milestones go to the project bin, from which they can be restored. The bin shows who deleted them and when.

Documents are the exception: deleting a document cannot be undone. The document, all of its versions and the uploaded files are removed for good, and there is nothing to restore from the bin. That is why only the project manager, a workspace administrator and the owner can do it, and the platform asks for confirmation first.