# The Roles page (admin)

Sidebar → **Roles**, admin only. A **role** is a bundle of settings that every member assigned to it picks up together: which security group their assistant runs under, which interface they see, which agent answers them, and whether new extensions reach them automatically. Picking a role for a person happens on [users.md](users.md); what that role *means* is edited here.

The list ships with three roles (on the standard profile): **Administrator**, **Member** and **Children**. Roles are data, not built-in categories — "Children" is a preset row the admin can edit like any other, and a role for guests or staff is just a fourth row. Administrator is the one exception: it is built-in, locked, and neither editable nor deletable (admins hold every permission implicitly, so there is nothing meaningful to configure).

## The role editor

Creating a role asks for an **ID** (a lowercase slug, permanent — it cannot be changed later) and a **Label**. Everything else is the same in create and edit:

- **Default security group** — the group the role's conversations run under when the member has not chosen otherwise. What a group permits is edited on the Security page, not here: [security-groups.md](security-groups.md).
- **Additional security groups** — extra groups the member *may* switch to in chat, via the shield pill. Leave it empty and there is no pill and nothing to choose: for most members one group is the whole point. The switch happens inside the conversation, and the server refuses any group the role does not list — whatever the interface shows.
- **Interface** — **Full** (all pages) or **Simple** (chat, inbox and projects only, with the assistant's internal reasoning hidden from the message list). Simple mode is a *simpler menu*, not a fence: every page remains protected server-side, and a simple-mode member can still own and share projects like anyone else.
- **Default assistant** — which chat agent the role's members talk to. Empty means the standard Assistant. The change lands on **new** conversations, picked up at the member's next login; an existing conversation keeps the agent it started with. (Project chats are unaffected: they always get the project's own coordinator.)
- **New plugins and connectors** — whether anything the admin installs reaches this role automatically. This is the one setting with a page of its own, because it interacts with per-person grants: see [access.md](access.md). Existing access is never changed by this switch, in either direction.
- **Attrs (JSON, optional)** — the raw store the fields above read from and write to. Editing it by hand is for attributes the form does not surface yet; normally you never touch it.

Two things happen the moment a role is saved, worth knowing before an admin edits one mid-afternoon:

- **Narrowing takes effect immediately, including on open sessions.** Removing a group from a role's allowed list pushes members who are logged in and sitting on that group back to a group they may use — the wider permission cannot be outrun by staying logged in.
- **Nothing is re-granted or re-taken.** The auto-grant switch only decides what happens *next time* something is installed or someone is added; per-person grants stand exactly as they are.

Deleting a role is refused while anyone is still assigned to it — the admin moves those members to another role first, from each person's page. Creating a role is always safe: a brand-new role starts with the standard self-service connector permissions (registering remote MCP servers and activating vetted catalog scripts), and nothing else.

## What this page is not

- **Not the people.** Assigning a role to a person, or changing it, is done from their page on [users.md](users.md) — and applies immediately, open sessions included.
- **Not the security rules.** What *allow / require / deny* means for a tool is edited per group on the Security page ([security-groups.md](security-groups.md)); here a group is only picked from a list.
- **Not a personality dial.** The interface mode changes which pages a member sees, and the default assistant changes *who answers* — neither changes how the assistant behaves within a conversation. That is the agent's prompt ([agents.md](agents.md)).

## Common questions

- *"Make the assistant simpler for my kid."* — Two different asks, one page: a **simple interface** (fewer pages, no reasoning blocks) and a **different default assistant** (a gentler agent). The Children preset sets both; a custom agent can be added too, see [agents.md](agents.md).
- *"Why can't I edit Administrator?"* — it is built-in and locked. Admins hold everything implicitly; there is nothing to configure.
- *"It won't let me delete the role."* — someone is still on it. Move them to another role from their own page, then delete.
- *"I moved my child to Member — why don't they have the plugins everyone else has?"* — a role change never hands out or takes back what was already granted. The admin ticks the boxes once on that person's page: [access.md](access.md).
- *"Can I show just one extra page in simple mode?"* — no; simple mode is chat, inbox and projects, as a set. Anything more is the full interface.
- *"Does changing the role log them out?"* — no. It applies to their open sessions immediately; nothing needs to restart.

## Related

- [users.md](users.md) — assigning a role to a person, and everything else on their page
- [security-groups.md](security-groups.md) — what a security group permits, and the shield in the chat
- [access.md](access.md) — the auto-grant switch in full: the open default, and why Children opts out
- [agents.md](agents.md) — chat agents, custom agents, and how the default assistant is chosen