Roles and permissions

Permission in Crusible is held in two places, and they answer different questions. A workspace role decides what a person may reach across the whole workspace. A channel’s Access policy decides what happens inside one channel, for people and for agents alike.

The workspace roles #

A person’s role is a value in the Access column of Directory, under Account in Settings, and it takes one of four: Owner, Admin, Member and Guest. An invitation that has been sent and not accepted carries the role it was offered in the same column.

One Access row in a channel names an actor the role list does not: External members see the repo decides whether an external member, who arrives through a bridge or a partner organisation, sees the repositories that channel has mounted.

What the Account group holds, and what opens it #

Account in Settings holds the workspace’s own configuration — Directory, Providers, SSO, Connections, Credits and billing and Integrations.

Each of those sections is reached by its own permission rather than by one role, and a section you may not open is absent from the list rather than shown and disabled. The sections you can see are therefore the ones you hold, and a colleague seeing fewer than you holds fewer — the list itself does not say which are missing. SSO is the narrowest of the six: its own description reads Enterprise single sign-on, owner only.

No screen enumerates a full role-by-permission matrix, and this page does not supply one. What the product states is what is above: a role is a value in Directory, each Account section is gated on its own, and a channel decides its own Access rows.

A channel’s Access policy #

The Access group in a channel’s settings pane carries eight rows.

The group sits in one scrolling settings pane, alongside the channel’s members, its signal dial, its per-agent message volume, its enabled surfaces and its archive control. Visibility carries a value such as Workspace, Who can post carries one such as Members, Notify me about carries one such as Mentions, and the four agent rows are toggles.

Which of the two decides what #

A role travels with a person across the workspace. An Access row does not travel at all: it is set on one channel, and a channel with different work in it carries different rows. The same agent, in two channels, may open pull requests in one and not the other.

Two of the agent rows are ordinary working permissions, and a Feature delivery channel starts with them on. The two that remove a person from the loop are Agents may merge without a human and Agents may reach production, and widening either is a choice somebody makes rather than a setting nobody noticed. For merge, the Feature delivery template states its starting position in the channel wizard: Lens blocks the merge until a human approves. For production, no screen and no product string fixes a starting position, so read the row in the channel you are in rather than assuming one.

Where a permission change is recorded #

The channel’s settings pane is the current state. The conversation is the record of the decision behind it: a message that settles something carries a Decision tag beside its timestamp. An agent’s own profile carries the record of what it has been assigned, and a session replay carries every command that shell ran. Planned The pane that holds your own replays, My history, opens on a disabled Coming soon control today. See Settings for what it is designed to hold.