workspace skill not found after update | Friends of the Crustacean 🦞🤝 | Page 1

dreamy pike Mar 13, 2026, 11:51 PM

#

Hi Krill,

I just ran an update and openclaw skills list only shows one of my 4 workspace skills. In addition, I get "23:41:32 [skills] Skipping skill path that resolves outside its configured root." during startup, but I suspect that is for the one skill that's symlinked from one agent workspace to another.

How can I find out why the other two (let's ignore the symlinked one for now) are not picked up? They worked fine in the past; I've had my agents use them plenty of times.

drifting scaffoldBOT Mar 13, 2026, 11:51 PM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

ripe ridgeBOT Mar 13, 2026, 11:55 PM

#

That warning is coming from a new-ish safety check in skills loading: OpenClaw now refuses to load any skill where the realpath of the skill directory or its SKILL.md would “escape” the configured root (workspace skills root, managed skills root, or skills.load.extraDirs). Docs mention it here: https://docs.openclaw.ai/tools/skills (see the “Security notes” section).

So there are basically 3 common reasons you’ll see “only 1 of N workspace skills” after an update:

You’re looking at a different workspace than you think (profile/agent/workspace changed)
One or more of the “missing” skills is also a symlink escape (sometimes it’s SKILL.md that’s symlinked, not the folder)
The skill isn’t being detected as a skill anymore (wrong filename casing / missing SKILL.md / directory layout changed)

Fastest way to pinpoint which of the 3 it is

Confirm what workspace the CLI is using (this catches the “wrong agent/workspace” case immediately):

openclaw --version
openclaw status

In the status output, check the workspace path.

#

Ask OpenClaw to explain skill eligibility / missing requirements:

openclaw skills check
openclaw skills list
openclaw skills list --eligible

If a skill shows up in list but not --eligible, it’s usually gating (requires.bins/env/config).
If it doesn’t show up in list at all, it’s discovery/path-related (layout, filename, symlink escape, parse failure).

For one of the missing skills, verify it’s actually inside the workspace skill root after resolving symlinks:

realpath "<workspace>/skills"
realpath "<workspace>/skills/<skillName>"
realpath "<workspace>/skills/<skillName>/SKILL.md"

If either of the last two realpaths is not under the first one, that skill will be skipped with exactly the warning you saw.

#

Fix (for the symlink/share case)

Instead of symlinking between agent workspaces, put shared skills in one of these supported places:

~/.openclaw/skills/<skillName>/SKILL.md (shared across all agents on that gateway), or
a shared folder referenced via skills.load.extraDirs (also shared)

Both avoid the “escapes root” skip.

If you paste the output of openclaw --version, openclaw status, and openclaw skills check, I can tell you which bucket you’re in (workspace mismatch vs symlink escape vs gating/layout) pretty quickly.

dreamy pike Mar 14, 2026, 12:05 AM

#

ok, here's the realpath output:

/mnt/d6/openclaw/ponyspace/skills/word-of-claw/SKILL.md
/mnt/d6/openclaw/ponyspace/skills/email/SKILL.md
/mnt/d6/openclaw/ponyspace/skills/word-of-claw/SKILL.md
/mnt/d6/openclaw/workspace/skills/qmd-local-search/SKILL.md

The qmd skill is the only one that shows up in openclaw skills list (and it is green there)

The third one is a symlink from /mnt/d6/openclaw/qwenspace/skills/word-of-claw/SKILL.md, but that's the easiest thing, I can just copy the file instead of symlinking it.

openclaw --version: OpenClaw 2026.3.12 (6472949) (Would be really surprising to get anything else, as I just upgraded and am looking at regressions.

(message length overflow, cont'd)

#

� OpenClaw  2026.3.12 (6472949) — Built by lobsters, for humans. Don't question the hierarchy.

Skills Status Check

Total: 52
✓ Eligible: 7
⏸ Disabled: 4
� Blocked by allowlist: 0
✗ Missing requirements: 41

Ready to use:
  � discord
  � gh-issues
  � github
  � healthcheck
  � skill-creator
  ☔ weather
  � qmd

Missing requirements:
  � 1password (bins: op)
  � apple-notes (bins: memo; os: darwin)
  ⏰ apple-reminders (bins: remindctl; os: darwin)
  � bear-notes (bins: grizzly; os: darwin)
  � blogwatcher (bins: blogwatcher)
  � blucli  (bins: blu)
  � camsnap (bins: camsnap)
  � coding-agent  (anyBins: claude, codex, opencode, pi)
  � eightctl (bins: eightctl)
  ✨ gemini (bins: gemini)
  � gifgrep  (bins: gifgrep)
  � gog (bins: gog)
  � goplaces (bins: goplaces; env: GOOGLE_PLACES_API_KEY)
  � imsg (bins: imsg; os: darwin)
  � mcporter (bins: mcporter)
  � model-usage (bins: codexbar; os: darwin)
  � nano-banana-pro (bins: uv; env: GEMINI_API_KEY)
  � nano-pdf (bins: nano-pdf)
  � notion (env: NOTION_API_KEY)
  � obsidian (bins: obsidian-cli)
  � openai-image-gen (env: OPENAI_API_KEY)
  � openai-whisper (bins: whisper)
  � openai-whisper-api (env: OPENAI_API_KEY)
  � openhue (bins: openhue)
  � oracle  (bins: oracle)
  � ordercli (bins: ordercli)
  � peekaboo (bins: peekaboo; os: darwin)
  � sag (bins: sag; env: ELEVENLABS_API_KEY)
  � session-logs (bins: rg)
  � slack (config: channels.slack)
  � songsee (bins: songsee)
  � sonoscli (bins: sonos)
  � spotify-player (anyBins: spogo, spotify_player)
  � summarize  (bins: summarize)
  ✅ things-mac (bins: things; os: darwin)
  � tmux  (bins: tmux)
  � trello (env: TRELLO_API_KEY, TRELLO_TOKEN)
  � video-frames (bins: ffmpeg)
  � voice-call (config: plugins.entries.voice-call.enabled)
  � wacli (bins: wacli)
  � xurl (bins: xurl)

I have no idea what those emoji at the front want to tell me, most of them are <?>, with a checkmark at a mac-only skill?

#

📎 message.txt

ripe ridgeBOT Mar 14, 2026, 12:09 AM

#

Those realpaths basically explain it.

OpenClaw’s workspace skill loader now enforces: the skill dir + its SKILL.md must resolve (via realpath) inside the configured skills root. Anything that “escapes” (usually via symlinks) is skipped with exactly that warning. Docs call this out here: https://docs.openclaw.ai/tools/skills (Security notes).

In your output, only this one resolves under the “workspace” tree:

✅ /mnt/d6/openclaw/workspace/skills/qmd-local-search/SKILL.md ← shows up (green)

The other two resolve under ponyspace:

❌ /mnt/d6/openclaw/ponyspace/skills/email/SKILL.md
❌ /mnt/d6/openclaw/ponyspace/skills/word-of-claw/SKILL.md

So from OpenClaw’s POV, those are “outside the configured root” (i.e. they’re being reached from the scanned root via a symlink / path indirection), and they’ll be skipped the same way as your cross-workspace symlinked one. In other words: it’s not “one symlinked skill”; you’re effectively in “skills are outside root” territory for all of the non-qmd ones.

How to verify quickly

Run this in the workspace that OpenClaw is actually using (from openclaw status):

#

ls -la /mnt/d6/openclaw/workspace/skills
openclaw skills list --verbose

You’ll almost certainly see email / word-of-claw as symlinks (dir symlink or SKILL.md symlink) pointing to ../ponyspace/....

Fix (supported patterns)

Pick one:

Copy the skill folders into the workspace’s skills/ (no symlinks out of tree).
Put shared skills in managed skills (works across agents on the same gateway):
- ~/.openclaw/skills/email/SKILL.md
- ~/.openclaw/skills/word-of-claw/SKILL.md
Or use a shared directory + config:
- put skills in e.g. /mnt/d6/openclaw/shared-skills/<name>/SKILL.md
- add it via skills.load.extraDirs (see https://docs.openclaw.ai/tools/skills-config)

#

If you paste your openclaw status (just the bit that shows the workspace path) + ls -la .../workspace/skills, I can tell you exactly which entries are symlinks and what to change.

dreamy pike Mar 14, 2026, 12:10 AM

#

you want to tellme, that only the primary agent can now have skills, the others don't?

ripe ridgeBOT Mar 14, 2026, 12:10 AM

#

Those “emoji” are not status indicators — they’re just each skill’s declared icon (metadata.openclaw.emoji) or a fallback glyph. Your terminal can’t render many of them, so you see � / <?>. And ✅ things-mac is just “this skill picked ✅ as its icon”, not “it’s eligible”. The real status is the section it appears under (“Ready to use”, “Missing requirements”, etc.).

Now, the important part: your openclaw skills check output confirms that email and word-of-claw aren’t being loaded/discovered at all (they’re not even in “Missing requirements”). That means it’s not gating (bins/env/config) — it’s discovery.

Given your earlier realpath outputs, the likely explanation is still:

OpenClaw is scanning the current agent’s workspace skills root (the one that contains qmd), and
the email / word-of-claw entries you think are “workspace skills” are actually being reached via a symlink that resolves into /mnt/d6/openclaw/ponyspace/..., i.e. outside the configured root → so they get dropped with:

Skipping skill path that resolves outside its configured root.

To prove it (and see exactly which ones are skipped)

Run:

openclaw --log-level debug skills list --verbose

and look for the [skills] Skipping ... lines — they include rootDir, path, and realPath, so you can match the skipped entries to email / word-of-claw.

#

Fix (supported sharing patterns)

Don’t symlink skills across agent workspaces anymore (that’s what this security check is blocking).
Either copy the skill folders into the current workspace’s skills/, or put them somewhere shared that’s meant for it:
- ~/.openclaw/skills/<name>/SKILL.md (shared across agents on the same gateway), or
- a dedicated shared folder + skills.load.extraDirs (e.g. /mnt/d6/openclaw/shared-skills), then put the skills there.

If you paste:

openclaw status (just the workspace path bit), and
ls -la <that-workspace>/skills

…I can point at the exact symlinks/entries that are causing the skip.

dreamy pike Mar 14, 2026, 12:13 AM

#

nothing there

📎 message.txt

ripe ridgeBOT Mar 14, 2026, 12:13 AM

#

Yeah, that output is confusing at first glance, but the key is:

1) The “emoji” are just the skill’s icon, not its status

They come from metadata.openclaw.emoji (or a fallback). Your terminal/font can’t render a bunch of them, so you see � / <?>.

So ✅ things-mac (… os: darwin) does not mean “things-mac is OK on Linux” — it just means that skill chose “✅” as its icon. The actual status is the section it’s listed under (“Missing requirements” in this case).

2) Your missing workspace skills aren’t being discovered at all

In openclaw skills check, if email / word-of-claw were found but ineligible, they would show up under Missing requirements.

They don’t show up anywhere, which means: OpenClaw didn’t load them as skills (discovery/path/layout issue), not “missing bins/env”.

3) `openclaw status` already caught the root cause

This line is the smoking gun:

WARN Workspace skill files resolve outside the workspace root

#

That’s the same rule as the startup log you saw: if skills/**/SKILL.md resolves (via realpath) outside the workspace root (usually because of a symlink), it gets skipped.

If you run the full report it’ll list the exact paths:

openclaw security audit

What to do

For the symlinked one: as you said, copy it instead of symlinking.
For sharing skills across agents/workspaces going forward, use a supported shared location instead of cross-workspace symlinks:
- Managed skills: ~/.openclaw/skills/<name>/SKILL.md (shared across all agents on that gateway)
- or a shared folder + skills.load.extraDirs (see https://docs.openclaw.ai/tools/skills-config)

Quick extra note (unrelated but important)

Your status shows the gateway is currently stopped (systemd … stopped, ECONNREFUSED). Once you fix the skill layout, you’ll still need to start it again for Discord to actually use the updated skill set.

If you paste the full “Workspace skill files resolve outside…” list from openclaw security audit (or just the paths it prints), I can tell you exactly which two skills are being skipped and from which workspace root they’re escaping.

dreamy pike Mar 14, 2026, 12:18 AM

#

That also only shows the one skill I know is symlinked and know how to fix. nothing on the other two missing ones

📎 message.txt

#

and yes, I stopped the gateway as my heartbeat needs one of the skills

ripe ridgeBOT Mar 14, 2026, 12:20 AM

#

Right — and that’s actually consistent with what’s happening.

openclaw skills list/check is not “all skills across all agent workspaces”. It’s scoped to the default agent’s workspace (whatever agent has default: true, otherwise the first agent in agents.list, otherwise main). That’s why:

security audit only reports the symlink escape (it scans all workspaces for security issues),
but skills list/check only shows the skills from the default agent workspace (plus managed + bundled), and
your two “missing” skills in /mnt/d6/openclaw/ponyspace/... won’t show unless ponyspace is the default agent’s workspace.

So there are two separate things:

The symlinked one (qwenspace → ponyspace) is being skipped by the new “realpath must stay inside root” rule. security audit is correctly flagging that.
The other two aren’t showing up simply because they’re in a different agent’s workspace than the one openclaw skills … is currently using.

How to confirm in one command

#

openclaw agents list --json

Look for which agent is marked "default": true and what its "workspace" is. That workspace is the one openclaw skills list/check is using.

What to do (depending on what you want)

If you want email + word-of-claw available to all agents: move/copy them to managed skills:
- ~/.openclaw/skills/email/SKILL.md
- ~/.openclaw/skills/word-of-claw/SKILL.md
If you want them only for the ponyspace agent: keep them in ponyspace/skills, but don’t expect them to show up in openclaw skills list unless that agent is the default (or unless we add a --agent flag to the skills CLI — which would be a legit feature request/bug report).

And yep: the “✅” on things-mac is just its icon, not a status indicator. The status is purely by section (“Missing requirements” etc.).

#

Makes total sense — and your security audit output is basically telling you exactly why the heartbeat is unhappy:

The heartbeat-running agent workspace is /mnt/d6/openclaw/qwenspace
It has skills/word-of-claw/SKILL.md that is a symlink escape to /mnt/d6/openclaw/ponyspace/...
Newer OpenClaw versions skip those escaped paths → skill never loads → heartbeat can’t use it → you stop the gateway.

Clean fix (best for “used by heartbeat / multiple agents”)

Move/copy the skill into managed skills, so every agent (and heartbeats) see it without any cross-workspace symlinks:

mkdir -p ~/.openclaw/skills/word-of-claw
cp -a /mnt/d6/openclaw/ponyspace/skills/word-of-claw/* ~/.openclaw/skills/word-of-claw/
# (copy the whole folder, not just SKILL.md, if it has scripts/assets)

Then delete/replace the symlinked copy in qwenspace/skills (or just remove it; managed skills will be picked up anyway), and sanity-check:

#

openclaw skills info word-of-claw
openclaw skills list

Then re-enable things

Once the skill shows up again, bring the gateway back:

openclaw gateway start
# or: openclaw gateway restart

If you want, paste openclaw agents list --json and tell me which agent/workspace the heartbeat runs under (it looks like third from your status), and I’ll tell you the “per-agent workspace” alternative too — but managed skills is the least annoying fix here.

#workspace skill not found after update

Fastest way to pinpoint which of the 3 it is

Fix (for the symlink/share case)

How to verify quickly

Fix (supported patterns)

To prove it (and see exactly which ones are skipped)

Fix (supported sharing patterns)

1) The “emoji” are just the skill’s icon, not its status

2) Your missing workspace skills aren’t being discovered at all

3) openclaw status already caught the root cause

What to do

Quick extra note (unrelated but important)

How to confirm in one command

What to do (depending on what you want)

Clean fix (best for “used by heartbeat / multiple agents”)

Then re-enable things

3) `openclaw status` already caught the root cause