Members and roles
Invite members and manage workspace permissions with the owner, admin, and member roles.
Everyone who joins a workspace is a member, and each member has one role: owner, admin, or member. Roles only control workspace settings and team management; day-to-day collaboration — creating issues, writing comments — is open to all members.
The three roles
| Action | owner | admin | member |
|---|---|---|---|
| View the workspace and collaborate day to day | ✓ | ✓ | ✓ |
| Change workspace settings | ✓ | ✓ | — |
Invite an admin or member | ✓ | ✓ | — |
Change or remove an admin or member | ✓ | ✓ | — |
Grant, revoke, or remove owner | ✓ | — | — |
| Delete the workspace | ✓ | — | — |
A workspace must always keep at least one owner: the last owner cannot be demoted, removed, or leave.
Roles do not decide who can run an agent. Each agent has its own Access scope, and owner and admin cannot bypass it to run agents they were not granted. See Agents.
Invite members
owner and admin send invitations from Settings → Members by entering an email and picking a role. Invitations can only grant admin or member; an owner must join the workspace first and then be promoted by an existing owner.
The invitee accepts by logging in with that email — no prior signup is needed. Invitations are valid for 7 days; resend after they expire. On self-hosted instances that restrict signup, invitees who do not yet have an account are still subject to the signup rules when registering — see Auth setup.
The invitation link appears only in the email; there is no place in the product to view or copy it. If the email fails to send, the invitation record still exists — revoke it and send a new one.
Change roles
An admin can move roles between admin and member, and can remove members holding those two roles. Any change involving owner — promoting, changing, or removing — can only be performed by an owner.
Role changes take effect immediately.
Remove a member
A removed member loses workspace access immediately. Issues, comments, and other collaboration records they created stay in the workspace.
Removing a member also deactivates the runtimes they own, archives the agents bound to them, and cancels tasks that have not finished. Grants the member received in agent Access scopes are cleared as well and are not restored automatically if they rejoin.
Next steps
- Issues — the work members and agents handle together.
- Agents — how workspace roles differ from agent Access.
- Daemon and runtimes — who owns runtimes and where they run.