Teams and permissions

Rivets controls access with two roles, a set of teams, and worker sharing. Roles decide who can administer the organization. Teams decide which repositories each member can see. Worker access decides whose machines each member can run work on.

Roles

The person who creates the organization is its first owner. Invited people join as members. An organization can have several owners, and always has at least one. See Manage members.

Teams

Owners manage teams under Settings › Teams on web, Mac, and iOS.

A team has a Name, a set of Members, and a Repository access grant:

• Everything: all current and future repositories.
• Selected repositories: only the repositories you pick. Selecting none grants no repository access through this team.

To create one, choose Create team (New team in the Mac and iOS apps), fill in the fields, and choose Save team (Save).

How access combines

A member’s access is the union of all their teams’ grants. They can use any repository granted by any of their teams. Removing a repository from one team does not remove access granted by another.

What access covers

Repository access applies everywhere: task lists and search, transcripts, changes and files, terminals, attachments, automations, MCP, and integrations. Someone without access to a repository cannot see its tasks at all.

Worker access

Repository access decides what a member can see. Worker access decides where they can run work.

Every worker has an owner: the member who registered it. For the Mac app’s built-in worker, that is whoever is signed in. A new worker is available only to its owner.

To share a worker, its owner opens Settings › Workers and chooses Manage access. Under Also available to, choose any of:

• Everyone in your organization, including future members.
• Specific Teams.
• Specific Members.

Only the owner can change who may use a worker, or move it to someone else with Transfer ownership. Other members see View access instead. Organization owners can remove any worker, but cannot change its access list.

What needs worker access

Using a worker means starting tasks or conversations on it, sending, editing, or deleting messages, cancelling runs, opening terminals, running scripts, saving files, discarding changes, and committing, pushing, or preparing pull requests. All of these also need access to the repository.

Reading does not. Transcripts, diffs, files, script output, and pull request status follow repository access alone, so teammates can watch work on a machine they cannot use. Team chat on a task also needs only repository access, because talking to teammates runs nothing on the worker. Sending the discussion on to the agent is a prompt like any other and needs worker access.

Automatic routing only picks workers the requesting member may use, and whose owner can read the repository. Pinning a task to a worker or cluster you cannot use is refused rather than ignored. Automations route as their creator.

Invites

Owners invite people from Settings › Organization on the web by choosing Invite member and entering an email address. In the Mac and iOS apps, use the Invite section of Settings › Members. If email delivery is not configured, Rivets shows an invite link to share instead. The invitee opens the link, signs in or creates an account, and chooses Accept invite.

You choose the new member’s access in the same step, so nobody joins to an empty workspace by accident:

• Repository access. Tick the teams they will join. Teams that grant every repository are ticked by default. To set up a team just for them, choose Create a team (New team in the Mac and iOS apps), name it, and give it all repositories or selected ones. It is created, with them in it, when you send the invite.
• Your workers they can run tasks on. Your own workers are listed. Ticking one shares it with the teams you chose. Only a worker’s owner can share it, so other members’ machines are never offered. See Worker access.

In an organization with no teams yet, the first invite starts on a new Everyone team with every repository. Untick it to invite the person with no access.

Accepting the invite adds the member to the chosen teams. Pending invites show the teams they will join, and a team deleted before the invite is accepted is dropped from it.

Each pending invite uses a seat until it is accepted or revoked. Settings › Organization shows seats used, counting members and pending invites. When all seats are used, you cannot send more invites. Revoke a pending invite from the invites list to free its seat. See Licenses and seats.

Manage members

Members are listed under Settings › Organization on the web and Settings › Members in the Mac and iOS apps. Each row shows the teams the member is in, or No repository access when they are in none. Owners choose Access on a row to change a member’s teams and the workers shared with them, with the same choices as an invite.

Change a role

Owners change a member’s role with the role picker on their row, choosing Owner or Member. On iPhone, tap the role to open its menu. Owners can change their own role too, as long as another owner remains. The change takes effect right away, including in the member’s open apps.

An organization always needs at least one owner, so the last owner cannot become a member: their role picker is disabled, and its tooltip says why. Make another member an owner first. Roles cannot change while the organization is suspended.

An organization-wide automation needs its creator to be an owner. If its creator becomes a member, the automation pauses. See Automations.

Remove a member

Owners choose Remove on a member’s row, then confirm with Remove from organization. On Mac, you can also right-click the row. On iPhone, swipe the row left, or choose Remove from organization… in the role menu.

Leave an organization

Anyone can leave an organization. Choose Leave on your own row, or Leave organization at the bottom of Members on iPhone, then confirm with Leave organization. Rivets then opens your next organization, or sign-up if you have none left.

The last owner cannot leave. Choosing Leave opens You can’t leave yet, which explains that an organization needs at least one owner. Make another member an owner first.

What removing or leaving does

Removing a member and leaving work the same way:

• They lose access to the organization and everything in it. Their open apps update straight away.
• Workers they registered are removed from the organization. Jobs running on those workers end as Worker was removed.
• Their API tokens are revoked. Their Linear account link, inbox entries, followed tasks, and project order in this organization are deleted.
• Their personal automations are deleted. Team and organization-wide automations they created stay, but pause because their creator is no longer in the organization.
• What they wrote in shared tasks, such as messages and team chat, stays, with their name and picture.
• Their seat is freed. You can invite them again later.

When access changes

Changes to roles, members, teams, and worker access take effect right away:

• Open clients update in place. Only the tasks someone lost disappear, and drafts are kept.
• Changing who may use a worker closes terminals on it for anyone who can no longer use it.
• Live connections and direct terminal tickets are revoked. Some existing connections can last up to 60 seconds before they close.
• Revocation stops further access. It cannot take back content someone already copied or downloaded.

Workers are a trusted boundary

Teams are application permissions. They control what Rivets shows and allows through its API. They do not isolate what happens on a worker.

Other settings that are owner-only

• The organization image. Organization names cannot be changed yet.
• Merge method and auto-archive under Settings › Git workflow.
• Organization and repository prompts under Settings › Prompts.
• GitHub and Linear under Settings › Integrations, and the Approve work from integrations setting there.