OpenClaw personal skill libraries: private skills on a shared Gateway
OpenClaw personal skill libraries, shipped in v2026.9.1, let every signed-in teammate on a shared Gateway keep their own skills without touching the workspace set or asking an admin. You create or import a skill under your identity, it stays private until you decide to share it, and sharing does not hand over edit rights. That last detail is the whole point: a shared Gateway can now serve a team while each operator keeps a personal toolkit.
Before this, skills on a self-hosted Gateway were effectively a single shared pile. One person added a skill and it landed in the same directory everyone else’s agents read. Fine for a solo setup, awkward the moment two people share one host. Personal skill libraries split ownership from location, so your skills follow your profile instead of the machine.
Contents
- What changed in v2026.9.1
- Personal vs workspace vs shared skills
- Create or import a personal skill
- Sharing without giving up edit rights
- Session behavior and revision pinning
- Who this is for
- FAQ
What changed in v2026.9.1
The openclaw skills library command and the Control UI’s Plugins → Skills → My skills panel now manage skills scoped to the caller’s signed-in identity, not the host. Per the OpenClaw v2026.9.1 release notes (#134068), a signed-in teammate can create, import, update, and reuse skills on a shared Gateway without shell access to the box.
Three properties define the feature:
- A library starts private. Nothing you create is visible to other operators by default.
- Sharing does not transfer edit rights. Other people can use a shared skill; they cannot rewrite it.
- Ownership can move to the team when a skill graduates from personal experiment to shared infrastructure.
A follow-up fix (#135593) reserves personal-skill ZIP-import capacity across profiles, so one operator importing a large bundle does not starve another. The design stays inside one trusted Gateway domain: this is a messaging-context and ownership boundary, not a host-admin boundary.
Personal vs workspace vs shared skills
OpenClaw now has three distinct places a skill can live, and they answer different questions. Workspace and shared-directory scope are covered in depth in choosing per-agent, shared, or workspace scope; personal libraries add the identity axis on top.
| Scope | Owner | Who can use it | Best for |
|---|---|---|---|
| Personal library | Your signed-in identity | You, until shared | A toolkit you carry across the agents you run |
| Workspace skills | The agent workspace | Agents in that workspace | A client- or project-specific workflow |
| Shared managed directory | The Gateway/team | All local agents (subject to allowlists) | A maintained baseline everyone should have |
The mental model: workspace scope is about which job, shared scope is about a common baseline, and personal libraries are about whose skill it is. On a solo Gateway the distinction barely matters. On a team Gateway it is the difference between a clean per-person toolkit and a directory nobody wants to prune.
Create or import a personal skill
You do not need host shell access. Two paths, per the creating-skills guide:
From the Control UI. Open Plugins → Skills → My skills, then create or import a SKILL.md bundle. The panel shows you the saved revision and whether it activated. That is the whole loop.
From the CLI. openclaw skills library manages the identified caller’s skills on the selected Gateway, using the same owner-aware service the Control UI uses. Import from a ZIP archive when you already have a bundle:
openclaw skills library import ./my-skill.zip
openclaw skills library listYou can also ask the agent to build one. Its skill_workshop tool writes through the Gateway’s authorized library service rather than editing managed revision directories directly, and it tells you whether the result is a published skill or a pending proposal. Ask explicitly to use the new revision in the current session, or to share it with the team.
A caveat worth knowing: native openclaw skills install still writes into the active workspace skills/ directory by default, and --global targets the shared managed directory. Personal libraries are the UI/skills library path, not the classic install path. Do not confuse the two when you are scripting setup.
Sharing without giving up edit rights
This is the part teams get wrong with a plain shared directory. In the old model, “share” meant “drop it where everyone can edit it,” and drift followed. Personal libraries separate the two.
When you share a personal skill, teammates get to run it. They do not get to change your copy. If a skill genuinely becomes shared work, ownership can move to the team, and from that point the team owns edits. Until then, your revision is your revision. This maps cleanly onto how OpenClaw already treats per-agent versus shared skill visibility: visibility and edit authority are separate concerns, and the new library respects that split at the identity level.
If your team is standing up a multi-operator Gateway for the first time, the team setup guide walks through the surrounding pieces: identity-aware auth, shared sessions, and roles that bound what each person can do. Personal libraries slot in as the “personal capability” layer on top of shared infrastructure.
Session behavior and revision pinning
Skills are selected per session, and a session holds onto the revision it started with. The release notes are explicit that revision delivery preserves the existing solo workspace-skills workflow and stays within one trusted Gateway domain. In practice:
- A new session selects from your enabled library skills, personal skills first, with stable ordering.
- A session keeps its selected revisions when another teammate joins it. Changing the assignee does not swap the skills out from under a running conversation.
- OpenClaw caps how many library skills a session loads (currently up to 64 enabled skills), so a large personal library will not flood a single session’s context.
If you rely on this in production, treat it the way you would any change surface: keep personal skills lean, and prune. The habits in avoiding skill sprawl apply to a personal library just as much as a shared one, and a skill you can run without host access is still code, so vet imported bundles before you trust them.
Who this is for
If you run OpenClaw alone, this changes little today. Your skills already followed you, because you are the only operator. The upgrade matters when a Gateway serves more than one person.
- Small teams on a shared host get per-person toolkits without carving up the filesystem or handing out shell access. See OpenClaw for small teams for the broader shared-Gateway pattern.
- Agencies and consultants can keep client-specific workflows in workspaces and personal utilities in their own library, so nothing leaks across engagements by accident.
- Operators building shared infrastructure get a clean layering: shared baseline in the managed directory, personal capability per identity, orchestration on top.
The net effect is small and structural. It does not add a new thing your agents can do. It changes who owns what, which is exactly the constraint that decides whether a shared Gateway stays usable past the second operator.
FAQ
Do personal skill libraries require a team plan? No. It is the same self-hosted OpenClaw Gateway. Team operation is configuration, not a separate edition. A solo user has the feature too; it just overlaps entirely with their single identity.
Can a teammate edit a skill I shared with them? No. Sharing grants use, not edit rights. Edit authority only moves when ownership of the skill is transferred to the team.
Where do imported ZIP skills go?
Into your personal library under your signed-in identity, managed by the owner-aware library service. This is distinct from openclaw skills install, which writes to the workspace or, with --global, the shared managed directory.
Does joining a running session change its skills? No. A session keeps the revisions it selected at start, and changing the assignee does not replace them. This preserves continuity for long-running conversations.
How many personal skills can one session use? A session loads up to 64 enabled library skills, personal skills first, with stable ordering. Keep the library pruned so the most relevant skills make the cut.
Sources: