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 boundaries stay per person no matter who you share a project with.
Teams own projects; projects hold threads
Signing up creates a personal team with you as its manager, 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 → Secrets is where they live, 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. Everything else — opening threads, delegating to sub-agents, approving proposals in the Inbox — is open to the team.
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
Two things stay per user regardless of team role:
- Git credentials. Tokens are stored per user, server-side, so every push and pull request happens with the author's own GitHub access — never a shared bot identity.
- Usage. Tokens and sandbox wall-time are metered per person, and caps pause the individual who crossed one rather than the team; 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.