Members
The Members page is where org admins invite people, assign roles, and remove access. Everyone who uses X4RGE under your company belongs here first — then you add them to teams and projects as needed.
This is not where you configure models, budgets, or integrations — that lives in Settings, Model control, and Usage. Members answers who is in the org and what org-wide role they hold. Project access is separate.
What this page is for
Org role (member, admin, super admin) controls dashboard and org-wide policy. Project membership controls which repos and agent work someone can use. A member with no projects may be blocked from agents if Require project assignment is on in Settings.
Who can see and change what
If you cannot invite or change roles, you may be member only — ask a super admin to promote you or send invites on your behalf.
Why members matters
Members is the front door for access. Pair it with Settings for invite rules and Project members for day-to-day work scope.
How members fits together
Typical flow: invite on Members → add to projects → confirm they can sign in on desktop or CLI.
In practice
Invite someone
Open Invite member
Enter their work email and choose a role (see below). They receive an email with a link to join your organization.
Pick the right role
When unsure, start with member and promote later.
Track pending invites
Pending rows show until the person accepts or the invite expires. Resend from the row menu if they missed the email; revoke if the invite was sent by mistake.
Default new contributors to member. Admin is for people who run the org dashboard — models, budgets, integrations, and membership — not every engineer needs that access.
Roles at a glance
Members get access to projects and repos through project membership, not org role alone. Admins shape what the whole org can use (models, spend, integrations).
What each role can do (summary)
*When Admins can invite is enabled in Settings.
After they join
Add to teams and projects
From Settings and Project members, assign the person to the right teams and projects.
Check project-assignment rules
If Require project assignment is on in Settings, members cannot use agents until they belong to at least one project.
Confirm they can sign in
They should complete sign-in and open the desktop, CLI, or Agents workspace once to verify access end-to-end.
Manage existing members
Change role
Open the member row → Change role. Promote to admin only after an internal access review; demotions take effect immediately for dashboard modules.
Review activity
Sort by Last active during periodic access reviews — especially for stale admin accounts.
Remove member
Remove member revokes org access immediately and clears their project and team memberships. Reassign open work first (see Offboarding).
Transfer ownership
Only a super admin can transfer organization ownership.
- Choose a successor who is already in the org (often promoted to admin first).
- From Settings → Organization, run Transfer ownership and confirm.
- The previous owner usually stays admin unless you change their role separately.
Ownership transfer is always recorded in the audit log. See Governance for audit context.
Offboarding
Removing a member or revoking their session takes effect right away. Plan handoffs before you click remove.
Before removing someone:
- Reassign in-flight agent runs and open pull requests
- Revoke personal User API keys from Integrations if they used automation
- Revoke active sessions in Settings → Sessions if needed
- Rotate shared secrets they had access to if your policy requires it
- Remove them from on-call and admin groups
If SAML or SCIM is connected in Settings, some users may join through your identity provider instead of email invites. Revoke stale pending invites to avoid duplicate accounts — follow your IT runbook.