Roles & permissions
Owners, managers, and members — who administers a team, and what stays yours alone.
Permissions in darting.dev live on the team. Teams & collaboration is the overview; this page is the detail — which role can do what, and which credential and billing boundaries apply when you share a project.
Teams own projects; projects hold threads
Signing up creates a personal team with you as its owner, and you can belong to as many teams as you're invited to. Projects belong to a team, not to the person who added them, so a project outlives whoever set it up.
team
└─ project (repo + run config + secrets)
└─ thread (branch + sandbox + conversation)
Anyone on the team can open a shared project's threads and pick up the work. A thread is shared with the project's team by default: a teammate can read it and send the next turn, so handing off mid-task takes no export step.
The three roles
| Role | Can do |
|---|---|
| Owner | Everything a manager can, as the team's ultimate administrator |
| Manager | Administer the team — membership and invites — plus the manager-gated project actions |
| Member | Open a shared project's threads, work in them, and send turns |
The split is deliberate: administration is gated, but doing the work isn't. Members don't need elevated rights to run agents, review diffs, or ship a pull request.
What's manager-gated
Managing project secrets is manager-gated — Project Settings → Sandbox variables and Live variables are where ordinary environment values live; vaulted credentials are in Secrets vault, and only owners and managers can change them. That keeps the credentials a sandbox runs with under the same control as team membership itself. See secrets & environment for how those values reach a running sandbox.
Membership and invites are gated the same way. Opening threads and delegating to sub-agents are open to the team. Knowledgebase Curate proposals are settled automatically by maintenance runs, not approved in an Inbox.
Private threads
Sharing is the default, not the rule. A thread you create as private stays visible only to you, even inside a shared project — useful for a spike you're not ready to explain, or work touching something sensitive. It's still a normal thread on its own branch and sandbox; only its visibility differs.
Pulling a teammate in
When you want a human's eyes rather than another agent turn, the +person control pings a teammate into the thread without running the agent. They arrive to the full transcript — the plan, the diffs, the video proof — instead of a summary you had to write.
Boundaries that don't depend on roles
Credentials and billing limits remain account-level, with these rules:
- Git credentials. Tokens are stored per user, server-side. The person who ships a thread authors its pull request with their own git-host access; when a project credential is used instead, the thread's creator is credited as a co-author.
- Usage. Tokens and sandbox wall-time are charged to a billing account according to the project's Billing setting. Caps apply to that payer; owner-paid work draws on the owner's limits. See usage & limits.
Together those mean a shared project never blurs who did what: the team decides who can join, and the audit trail in git and collections records who acted.