Workspaces

A workspace is the level above scopes: workspace › scope › item. It holds scopes, and the items in them, for one team or group, so one instance can serve several. Every scope belongs to exactly one workspace, chosen when the scope is created, and an item's workspace is its scope's.

global › @platform › @platform/code-reviewer
acme   › @acme-infra › @acme/acme-infra/deploy

Outside global, the workspace is part of an item's name: @acme/acme-infra/deploy. A scope's name is unique within its workspace, so two workspaces may each have a scope of the same name (see Naming rules). A workspace and a scope may share a name.

• In the catalogue and on an item's page, an item shows its full name, such as @acme/acme-infra/deploy, and its page's address names the workspace too: /workspaces/acme/items/acme-infra/deploy. Under its name, each card and the item's page also say its workspace, a link to the workspace's page, and its scope, global included. Install it by its full name: rmk install @acme/acme-infra/deploy.
• Once you see a workspace besides global, the catalogue's Filters offer Workspace, with the workspaces you see.
• A workspace is public or private. Everyone signed in sees a public workspace's scopes and items, and installs and depends on them; a private one's are seen only by its members and root. Either way, its members are the ones who submit and review there.

Every instance has a workspace called global, described as “Everyone on this instance”. It's public, and it can't be renamed, edited or deleted. The scopes that existed before workspaces are in it, and a new scope goes in it unless another workspace is chosen.

Everyone but root is a member of global, and nobody leaves it: a new user starts there as a user. Their role there can change, and they can be added to other workspaces too.

The name global is reserved for it: no other workspace can take it, though a scope can.

Everyone has a workspace of their own, made with their account: a place to build items for yourself, install them and try them out, without asking anyone. It's private, always, and only yours: nobody can be added to it or ask to join it.

• Its name comes from your email, the part before the @: [email protected] gets ana-silva (or ana-silva-2 when that's taken). Its items are named like any outside global: @ana-silva/tools/lint. You can rename it.
• Workspaces, in the sidebar, lists it first, as Personal, with Manage. Its page has its scopes, with Create scope, and Rename and Edit description: no members, no requests, no visibility to change, and it's never deleted. The workspace switcher at the top of the sidebar shows it, and opens its page. You're its admin, but that doesn't give you root's Users, Audit log and Settings.
• New item, the catalogue's Workspace filter and rmk export list it first, as Personal.

Released without review

Only you and root can see or install what's in it, so a second pair of eyes would protect nobody. What you submit there is approved at once: the button says Submit, not Submit for review, and the submission's page says “Approved by you: personal workspaces aren't reviewed.”, with what it can do listed below, as a reviewer would have seen it. Release it when you like. It never reaches the review queue, and its versions are marked as not reviewed: an item's page says “Released without review.”

Who sees it

• Anyone else gets what a name that doesn't exist gets: its items, its page and its join link answer as unknown.
• Root sees every personal workspace and its items, and can rename one, edit its description or create a scope in it, but isn't a member. Root's catalogue, search and plugin marketplace leave out other people's personal workspaces, unless the Workspace filter names one; root's Workspaces page lists them on its Personal tab, with their owners.
• Its items can depend on its own items and on public workspaces' items, and nothing outside depends on them.
• To share a scope, move it to a team workspace (see Moving a scope). Once you've released versions in it, someone else approves the move, and that reviews them.

The workspace switcher at the top of the sidebar (in the Menu on a phone or tablet) chooses the workspace you're working in. It starts at All workspaces.

• It lists All workspaces and the workspaces you're a member of, your personal one first; the one you're in is ticked. Each also has an arrow that opens its page, and Manage workspaces opens the Workspaces list.
• Once you choose one, the Catalogue, Reviews (every tab) and My submissions show only that workspace, with Showing acme only · Show all under their heading, and New item starts on its first scope. Show all goes back to every workspace.
• It stays chosen on every page, in this browser, until you choose another or Show all.
• The Catalogue's own Workspace filter, under Filters, sets the same ?workspace= and also lists public workspaces you aren't in. It changes only what that page shows: the switcher's choice stays, and Show all clears both.
• The address says it: those pages carry ?workspace=acme, so a link you send shows the same workspace to whoever opens it, within what they can see. ?workspace= with nothing after it shows every workspace.
• It's a filter, not a permission: it changes what you see, never what you may do. The sidebar's counts next to Reviews and Requests still count every workspace, so nothing waiting elsewhere is missed. Nothing else is filtered: Home, Workspaces, item pages and Requests stay the same.
• A workspace you can't see filters to nothing: the Catalogue says “No workspace acme you can see”, the same as for a name no workspace has.
• rmk, the MCP server and the API have no current workspace: use the item's full name, or --workspace where a command takes it.

Every workspace is public or private. global is always public, and personal workspaces are always private.

• Public: everyone signed in sees its scopes and items, installs them and depends on them.
• Private: only its members, in any role, and root see its scopes, items and submissions. Its items show a lock and Private beside their workspace, in the catalogue and on their page; a personal workspace's say (personal).

To everyone else, it doesn't exist

Someone who isn't a member gets exactly what they'd get for a name that doesn't exist, never “forbidden”, so nobody can find out what a private workspace holds by trying names:

• The catalogue, search and the home page leave its items out, and the Workspace filter leaves the workspace out. An item's page and its versions answer “not found”.
• rmk and the MCP tools answer as for an unknown item, such as @acme/acme-infra/deploy isn't a published item. (see Installing). So do the registry API, tarball downloads and the plugin marketplaces.
• A draft in one of its scopes says “There's no scope @acme/acme-infra you can use. Root and a workspace's admins create scopes.”, the same as for a scope that doesn't exist. A public item's Used by doesn't list private items that depend on it.

Dependencies

A private workspace's items can be dependencies only of items in the same workspace. An item can depend on its own workspace's items and on public ones (see Dependencies). That way an item never stops installing for people who can't see what it needs.

Choosing and changing it

• New workspace asks for its visibility, Public chosen.
• Root changes it on the workspace's page, with Make private or Make public. A workspace's admins can't: it changes what everyone else sees and depends on.
• Make private first lists what it meets. While released items outside the workspace depend on its items, it's refused, with those items listed: release them without the dependency first. Open submissions outside that depend on it are only a warning: they'll fail at release.
• Make public asks first. Both changes are in the audit log, such as “Made workspace acme private”, and take effect from the next request.

Losing access

When someone is removed from a private workspace, or a public one turns private, they stop seeing its items from their next request: installing or updating one says it's not found, and it leaves their plugin marketplace. Nothing they already installed is touched.

What private doesn't do

• It isn't encryption: the database and storage hold every workspace's items together, and whoever runs the instance can read them. Root sees every workspace.
• A name already written somewhere stays there: in a lockfile, in a git mirror built with --workspace, or in an outside item's version that depended on it before the workspace turned private and was yanked. The audit log, which only root reads, names private items too.

Each workspace has members, and each member has a role there: user, moderator or admin (see Who can do what). Someone can run one workspace as its admin and be a plain user in another. Everyone is a member of global. Root works in every workspace without being a member of any.

• Users create drafts, propose changes and submit in the workspace's scopes, comment on their own and release their own once approved. The new draft form and rmk export list only the scopes of your workspaces.
• Moderators also review, approve and release the workspace's submissions, look after its items' versions, and approve or decline requests to join it. Reviews shows the submissions of the workspaces you moderate; it's in the sidebar once you moderate one, and the workspace switcher shows one workspace at a time.
• Admins do everything a moderator does there, and run the workspace: they add and remove its members, change their roles (admins included), create its scopes and edit its description. Approving a request to join, they can make the person a moderator rather than a user. They do it all on the workspace's page; Users, Audit log and Settings are root's.
• Anyone else signed in browses, installs and depends on a public workspace's items, and doesn't see a private one's. Drafting, proposing or submitting there says “You aren't a member of the acme workspace. Ask to join acme to propose changes.”, with an Ask to join acme link (see Joining a workspace).

Who manages members: root, in every workspace, and each workspace's admins, in theirs. On a workspace's page, its Members tab lists them; Add members finds people by email or name and gives them a role; each member's role can be changed, and Remove takes them out after a confirm. Root also sets all of one person's workspaces at once from Users (see Administration). Every change is in the audit log.

• Nobody changes or removes their own membership, so an admin can't lock themselves out by mistake: another admin or root does it.
• Nobody is removed from global; their role there can still change.
• Root isn't a member and can't be added: root works everywhere. A disabled user keeps their memberships.

Someone who leaves a workspace keeps their drafts and open submissions there: they can read and withdraw them, but not change, submit or release them, and the workspace's moderators and admins can still decide them.

Anyone signed in can ask to join a workspace they aren't in, and root or the workspace's moderators and admins answer. The join link is the instance's address followed by /workspaces/<name>/join.

Asking

• Workspaces, in the sidebar after Catalogue, lists the workspaces you see: global (“Everyone”), the public ones, and the private ones you're in, with your role in each. A public one you aren't in offers Ask to join: add a message if you like, up to 500 characters, for whoever answers, and send.
• A private workspace isn't listed. Root or its moderators or admins send you its join link, /workspaces/<name>/join, which shows the name and the same form. The link holds no secret: it only lets you ask, and a person decides. It looks the same for a private workspace as for a name no workspace has, before and after you ask, so it doesn't confirm that a name exists.
• Your request shows as Requested, with Cancel, on the Workspaces page and on the link. The ones you sent from a link are listed under Your other requests, by name.
• A “not a member” refusal links to the same form: under Propose a change on an item's page, on a draft you can no longer change, and in Submit selected's results.

Answering

• Root and the workspace's moderators and admins see Requests in the sidebar, with how many wait, while any do (for root and admins, the scope moves waiting for them count too, and the page lists them under Scope moves). It opens Requests to join: every request they can answer, oldest first, with its workspace and message. Root and a workspace's admins also find its requests on its Requests tab, on the workspace's page.
• Approve adds the person as a user; root and the workspace's admins can pick moderator instead. Decline can give a reason, which the person sees. When two people answer at once, the first answer counts and the other is told “Already answered.”

After the answer

• Approved, the workspace shows on your Workspaces page with your role. Declined, you see the date and the reason, and can ask again 7 days later, or at once if you've been added to or removed from the workspace since.
• One open request per workspace, and at most 10 open at once. Adding you to the workspace directly approves your request; disabling your account cancels your requests.
• Each step (asked, approved, declined, cancelled) is in the audit log; the message and the reason aren't.

Everything about workspaces is on Workspaces, in the sidebar (the workspace switcher at its top also opens the ones you're in). The page lists the workspaces you see, each name opening its page. Root's list has every one, global first, with each one's description, visibility, number of scopes and moderators, admins included (“None” when only root reviews there); search by part of a name or description, and sort by name or creation date. Two tabs above it, Shared and Personal, each say how many match the search; Personal lists everyone's personal workspaces, each with its owner's email (the search matches it too).

A workspace's page is for everyone who sees the workspace: its description, its visibility, your role there (or Ask to join), and its scopes. What you may do there shows only to you if you may: its admins and root see more.

• Scopes (the default tab): Create scope makes one in this workspace, and each scope's icons edit its description or move it (see Moving a scope), for root and its admins. A scope's move shows under its description.
• Members, for root and its admins, lists name, email, role and when each was added, by name or by date added, 50 a page; search by email or name, and filter by role. Add members finds people by email or name (not those already in it, root or disabled users), lets you pick several, and gives them one role. A member's role changes as soon as you pick another, and Remove asks first. Your own row can't be changed, and nobody is removed from global.
• Requests, for those who answer them, lists the open requests to join it, oldest first, with each message, and, for root and its admins, the scope moves into it waiting for an answer.

Users, Audit log and Settings are root's alone: a workspace's admins manage their workspace from its page, and its old address under /admin opens that page.

• New workspace, root's, on Workspaces: a name and a description. The name follows the scopes' rules (lowercase letters, digits and hyphens, up to 64 characters, not starting or ending with a hyphen), the scopes' reserved names and global are taken; root and its admins can rename it later. It also asks whether the workspace is public or private, public chosen; root can change that later.
• Edit description, on a workspace's page, is for root and its admins. Root's Make private or Make public changes who sees it: Make private lists the items outside that depend on it, and is refused while there are any. global's page has none of these, nor Rename or Delete; a personal workspace's has only Rename and Edit description.
• Rename, on a workspace's page, is for root and its admins; global keeps its name. The new name follows the same rules and can't be another workspace's. Its items take it: @acme/team/lint becomes @acme-platform/team/lint. Their old names keep working for installs, lockfiles and dependencies, and rmk moves projects to the new names as they update; in Claude Code they show as new plugins. Drafts and submissions not released yet take the new names too. Links to the workspace (its page and its join link) stop working, and so does the old name in rmk search --workspace, rmk feed build --workspace and CI workflows that name it: the old name is a name no workspace has, and another workspace can take it. Its members, scopes and requests stay.
• Delete is root's, and works only while the workspace has no scopes (greyed out with “Move or remove its scopes first.”): move them out first (see Moving a scope). Requests to move a scope into it are closed with it.
• Creating a scope: on a workspace's page, Create scope makes one in that workspace, for root and its admins; there's no other place to create one. A scope can move to another workspace later (see Moving a scope).

Creating a workspace, changing its description or visibility, renaming it, deleting it, and adding, changing and removing its members are recorded in the audit log.

A scope moves to another workspace with every item in it: a team takes over a scope, something built in a personal workspace becomes a team's, or something proven in a team goes to global for everyone. On a workspace's page, each scope has Move… for root and the workspace's admins (for a personal workspace, its owner).

Who has to agree

• Root moves at once, after two confirmations: the second asks for the scope's name, typed.
• An admin of global moving into global moves at once the same way. Anyone else moving into global asks, and only root answers.
• An admin of the target workspace, or someone moving into their own personal workspace, moves at once after one confirmation.
• Anyone else asks to move, with an optional message: the target's admins or root answer. Nobody moves a scope into someone else's personal workspace.
• Not reviewed: a scope whose released versions weren't reviewed (from a personal workspace) always asks, answered by someone other than you: root, or a target admin (root alone for global). Approving the move reviews them, in that person's name.

The Move dialog

Pick where to, and the scope's name there: its own, unless the workspace already has a scope by that name (“acme already has a scope called infra: pick another name for it there”). As you pick, it says what changes: each item's new name (@infra/deploy → @acme/infra/deploy), who will see and review them, open work by people who aren't the target's members (they can read and withdraw it, not change it), versions not reviewed, and what refuses the move. Anything in a workspace you can't see is counted, never named. The button says what happens: Move scope or Ask to move.

What refuses a move

• Released items outside a private target that depend on the scope's items: they would stop installing for people who can't see the target.
• The scope's own released versions or submissions that depend on another private workspace's items, which they couldn't depend on there.
• A new name that's another item's old name, or a scope name taken there.

Each is checked when you ask and again when someone approves, which then leaves the request open and lists what refuses it. Open submissions outside that depend on the scope are a warning: they'll fail at release.

Answering

Requests wait on the Requests page, under Scope moves, and on the target's Requests tab: the scope and its items, where from and to, its name there, who asked, the message, and what would refuse it now. Approve checks again and moves it; Decline can give a reason, shown on the scope's row. Until then the row says “Moving to acme”, with Cancel for its asker and the workspace's admins. One move per scope waits at a time. If whoever asked is no longer an admin of the scope's workspace when it's approved, the request is cancelled.

After the move

• Its items have the target's names. Their old names keep working for installs, lockfiles and dependencies, and rmk moves projects to the new ones as they update; in Claude Code they show as new plugins. Moved back, a scope takes its earlier names again.
• Who sees them follows the target, from the next request: people who can't see it get “not found”, and their installs stop updating. Its moderators and admins review the open submissions, which name the items anew.
• Versions, tags and download counts don't change. Every step is in the audit log.