PathruleRoles and permissions
The roles in a Pathrule organization, how a workspace is shared with the whole organization or kept private, and how the database enforces every read and write the same way across the web console, the CLI, VS Code and MCP.
On this page
Pathrule starts as a solo tool and grows into a team product. When you invite colleagues, the question becomes who can see and change what. This page covers the roles you assign, how access narrows from organization to workspace, and where the check actually runs.
The short version: roles are assigned at the organization level, access can be narrowed per workspace, and every read and write on a Pathrule Cloud workspace is checked by the database against your signed-in user. The same check applies whether the request comes from the web console at app.pathrule.io, Pathrule CLI, the VS Code extension, or the MCP server an AI client speaks.
A Pathrule Local workspace has no account and lives on one machine, so roles do not apply to it. When you move its folder to Pathrule Cloud, setup can copy its knowledge into a Cloud workspace, where they do.
The four roles
Roles are assigned per person at the organization level. An owner or admin invites a colleague by email and picks their role, Editor by default; the colleague accepts the invite to join. Invite from Members in the web console, or from the terminal:
pathrule invite colleague@example.com --role viewer
From the terminal the role is admin, member or viewer. member is the CLI's name for Editor and the default, so pathrule invite colleague@example.com invites an Editor. The command prints the invite link, valid for 7 days, and says whether Pathrule Cloud e-mailed it.
| Role | Can do |
|---|---|
| Owner | Organization administration and ownership controls. The organization must retain an owner. |
| Admin | Manage membership and permitted roles, and administer workspaces. |
| Editor | Read and write content (memories, rules, skills) in the workspaces they can access. The everyday contributor role. |
| Viewer | Read content in the workspaces they can access. No writes. |
A few guardrails follow from this:
- Ownership changes require owner authority, and the organization must keep an owner.
- Ownership and membership changes are checked on the server, including the requirement to retain an owner.
Membership changes require a current authorized session. Sensitive workspace archive and delete actions additionally require fresh authentication.
Seats and plans
Every person in the organization takes a seat, whatever their role.
- Solo and Pro are for one person. They have no invites; to work with others, move to Team.
- Team is billed per seat, at least two, the owner included. Inviting beyond the seats you pay for needs another seat; with fewer seats than members, everyone keeps access and new invitations wait.
- Enterprise seats are agreed with sales.
Seats and invoices live under Billing in the web console; pathrule billing opens it from the terminal. See Pathrule Web.
Workspace access: organization-wide or private
A role sets what a person can do. A workspace's access mode sets who can reach it at all. Each workspace is one of two modes.
- Organization-wide. Every member of the organization has access, at their org role.
- Private. Only people explicitly added to the workspace have access. Org membership alone is not enough.
Owners and admins switch the mode in the web console settings under Workspace, Access. When a workspace becomes private, only its explicit workspace members have access. Review and add the people who need it; organization membership alone no longer grants access. Inside a private workspace, a person's workspace role decides what they can do there, so you can give someone a different level of access than they have elsewhere.
Losing access is non-destructive
Permission changes never destroy work and rarely hide it.
- Lose write access (for example, moved from Editor to Viewer) and nothing disappears. You can still read everything you could before; writes from you, or from an assistant working as you, are refused.
- Lose access to a workspace (removed from a private workspace, or from the organization) and only then does its content drop out of view for you. The content stays with the team.
The same boundary reaches the assistant. When an AI client tries to write where a member cannot write, the MCP tool call comes back with a clear permission-denied result the assistant can relay to you in plain language, rather than failing silently or appearing to succeed. The context an assistant receives, and the instruction files Pathrule writes for it, only ever come from workspaces that member can read.
Where the check runs
None of this is enforced in the application you happen to be using. Every read and write on a Cloud workspace runs through a database access check resolved against your signed-in user, your organization membership, and the workspace's access mode. Access checks are part of the server’s database operations, rather than a hidden button in the interface.
- One check for every surface. The web console, Pathrule CLI, the VS Code extension, the local MCP server and Remote MCP all go through the same database-enforced access control. A change from the terminal and a write from an AI client are gated by the same rules.
- No shared admin key. Each surface carries a short-lived, per-user token, never a shared service key that could unlock another team's data. A leaked client can only ever reach what that user already can.
- Server-side resolution. Membership and workspace roles are resolved on the server, not trusted from the client, so an edited request cannot grant itself access it was not given.
For the full picture of how the cloud is gated, see the security overview.
On self-hosted
Enterprise self-hosted runs the same role and permission model in your own Cloudflare account. The roles and the workspace access modes behave the same way; the difference is that the data and the database live in your account. Single sign-on through your own identity provider is arranged under the Enterprise agreement and maps onto the same organization roles described here. See Enterprise self-hosted for how that deployment works.