Roles and permissions
Understand organization access and the separate authorization used by chat integrations.
Devboxes permissions belong to an organization. The same person can have different roles in different organizations. A manager or developer job title does not grant a product permission.
Organization roles
| Action | Owner | Admin | Member |
|---|---|---|---|
| Read organization projects and sessions | Yes | Yes | Yes |
| Configure projects, repository connections, and model accounts | Yes | Yes | No |
| Dispatch runs and send session follow-up instructions from the dashboard or CLI | Yes | Yes | No |
| Invite or remove members, cancel invitations, and change a member's role | Yes | Yes | No |
| Export or delete organization data | Yes | No | No |
These permissions require an active membership and account. Member access does not include secret values or the model sources on a runner. Organization membership alone does not grant access to platform administration.
Invitations
An owner or authorized administrator invites a person and selects their role. The invited person accepts the link using the intended account. Pending invitations can expire, be cancelled, or be replaced with a new link.
Share an invitation only with its intended recipient. Replacing or cancelling it stops the previous link from granting access.
Chat authorization is different
A configured channel uses the authority of the owner or admin who configured its project assignments. People and apps allowed to post there may be able to trigger work without individual Devboxes membership. Do not use the organization role table as a description of chat-channel access.
Review chat integration access before assigning sensitive projects to a channel.
Platform administration
Platform administrators manage the Devboxes deployment. Becoming an organization owner or admin does not grant platform administration access. Ask your deployment operator for help with service configuration or an installation-wide failure.