Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Skills not loading in agent context from ~/.openclaw/workspace/skills/ [2 pull requests, 8 comments, 5 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#43735•Fetched 2026-04-08 00:17:44
View on GitHub
Comments
8
Participants
5
Timeline
15
Reactions
0
Author
che1404che1404
Participants
AntiMoronAntiMoronche1404che1404fyq163fyq163maximizeGPTmaximizeGPTpigd0gpigd0g
Timeline (top)
commented ×8cross-referenced ×2referenced ×2subscribed ×2

The OpenClaw agent context is not loading all available skills from ~/.openclaw/workspace/skills/ directory. Only a subset of skills appear in the initial context under <available_skills>, causing agents to be unaware of existing skills.

Root Cause

The OpenClaw agent context is not loading all available skills from ~/.openclaw/workspace/skills/ directory. Only a subset of skills appear in the initial context under <available_skills>, causing agents to be unaware of existing skills.

Fix Action

Workaround

Manually scan the skills directory when needed:

ls ~/.openclaw/workspace/skills/

PR fix notes

PR #1: fix: skills snapshot not invalidated after gateway restart — missing skills in agent context

Description (problem / solution / changelog)

After a gateway restart, globalVersion reset to 0, and snapshots built post-restart were also stored with version = 0. On subsequent turns the version comparison (0 === 0) treated the stale snapshot as current, so skills added between restarts (or since the previous restart cycle) were silently dropped from agent context. The filesystem watcher uses ignoreInitial: true and never fires for pre-existing skills, so the version counter never self-corrected.

Summary

  • Problem: let globalVersion = 0 in refresh.ts resets every restart. Snapshots built after any restart store version = 0. Next restart: snapshotVersion = 0, existingSnapshot.version = 0 → shouldRefresh = false → stale snapshot cached forever.
  • Why it matters: Skills added to ~/.openclaw/workspace/skills/ between restarts are invisible to agents until the watcher fires — which it never does for files that already exist at startup.
  • What changed: Three surgical fixes:
    1. refresh.ts: globalVersion = Date.now() at module load — each restart produces a unique non-zero epoch, making every prior cached snapshot unconditionally stale.
    2. session-updates.ts: Avoid double filesystem scan introduced by (1) — reuse the snapshot already built by the first-turn block when version === snapshotVersion.
    3. commands/agent.ts: needsSkillsSnapshot now includes existingSnapshot.version !== snapshotVersion, closing the same gap on the CLI openclaw agent path.
  • What did NOT change: Scan limits, skill loading logic, watcher configuration, or any behavior when skills are unchanged between restarts.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Related #43735
  • Related #44898

User-visible / Behavior Changes

After a gateway restart, the agent's <available_skills> block will now reflect the current on-disk state of ~/.openclaw/workspace/skills/ rather than the snapshot cached in a previous process lifetime.

No config or API changes.

Security Impact (required)

  • New permissions/capabilities? No
  • Secrets/tokens handling changed? No
  • New/changed network calls? No
  • Command/tool execution surface changed? No
  • Data access scope changed? No

Repro + Verification

Environment

  • OS: macOS / Linux
  • Runtime/container: Node 22+
  • Model/provider: any
  • Integration/channel (if any): any
  • Relevant config (redacted): default workspace (~/.openclaw/workspace/)

Steps

  1. Start gateway. Send a message — note <available_skills> in context.
  2. Add a new skill directory under ~/.openclaw/workspace/skills/<new-skill>/SKILL.md.
  3. Restart the gateway twice (to reproduce the double-zero version collision).
  4. Send another message.

Expected

  • New skill appears in <available_skills>.

Actual

  • New skill absent; only the pre-restart snapshot contents shown.

Evidence

  • Failing test/log before + passing after

All 521 cron tests and 106 skills tests pass after the fix. The run.skill-filter.test.ts suite specifically covers the resolveCronSkillsSnapshot version-comparison path (mock returns 42; snapshot version: 42 → no rebuild; snapshot version: 41 → rebuild), confirming the comparison logic is intact.

Human Verification (required)

  • Verified scenarios: version initialization produces non-zero value; post-restart snapshot version mismatch triggers rebuild; second turn with matching version skips rebuild; first-turn block reuse prevents double scan.
  • Edge cases checked: first-ever session (no existing snapshot); ongoing session after single restart; ongoing session after multiple restarts; snapshotVersion > 0 guard in shouldRefreshSnapshot still respected; CLI openclaw agent path consistency.
  • What you did not verify: live end-to-end gateway restart on real hardware with >50 skills.

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

  • Backward compatible? Yes
  • Config/env changes? No
  • Migration needed? No

Failure Recovery (if this breaks)

  • How to disable/revert this change quickly: revert src/agents/skills/refresh.ts line let globalVersion = Date.now() back to let globalVersion = 0.
  • Files/config to restore: src/agents/skills/refresh.ts, src/auto-reply/reply/session-updates.ts, src/commands/agent.ts
  • Known bad symptoms: snapshot rebuilt on every gateway start (expected and cheap); if somehow Date.now() returns 0 (impossible in practice) old behavior resumes.

Risks and Mitigations

  • Risk: One extra skills directory scan per session per restart (first turn post-restart now always rebuilds).
    • Mitigation: Scan is synchronous and fast for typical skill counts; the double-build optimization in session-updates.ts prevents a second scan within the same first turn.
<!-- START COPILOT CODING AGENT TIPS -->

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

Changed files

  • src/agents/skills/refresh.ts (modified, +6/-1)
  • src/auto-reply/reply/session-updates.ts (modified, +18/-12)
  • src/commands/agent.ts (modified, +4/-1)

PR #48089: fix: skills snapshot not invalidated after gateway restart - AI assisted

Description (problem / solution / changelog)

…skills in agent context (#1)

  • Initial plan

  • fix: invalidate stale skills snapshots after gateway restart

Initialize globalVersion to Date.now() in refresh.ts so each process restart produces a unique starting version. Previously, globalVersion reset to 0 on every restart causing cached snapshots (also version=0) to appear current and never be refreshed, hiding skills added between restarts.

Also fix a double-build in session-updates.ts: when shouldRefreshSnapshot is true but the first-turn block already built a fresh snapshot with the current snapshotVersion, reuse it instead of scanning the filesystem twice.

Also fix needsSkillsSnapshot in commands/agent.ts to check version staleness (not just whether a snapshot exists), applying the same consistency on the CLI agent path.

Fixes openclaw/openclaw#43735

Summary

Describe the problem and fix in 2–5 bullets:

See issue - https://github.com/openclaw/openclaw/issues/43735

Change Type (select all)

  • [X ] Bug fix -
  • Feature
  • Refactor
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • [X ] Gateway / orchestration
  • [X ] Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #

https://github.com/openclaw/openclaw/issues/43735

  • Related #

User-visible / Behavior Changes

List user-visible changes (including defaults/config).

None

Security Impact (required)

  • New permissions/capabilities? (Yes/No) - N
  • Secrets/tokens handling changed? (Yes/No) - N
  • New/changed network calls? (Yes/No) - N
  • Command/tool execution surface changed? (Yes/No) - N
  • Data access scope changed? (Yes/No) - N
  • If any Yes, explain risk + mitigation:

Repro + Verification

Environment

  • OS:
  • Runtime/container:
  • Model/provider:
  • Integration/channel (if any):
  • Relevant config (redacted):

Steps

See issue.

Expected

Actual

Evidence

Attach at least one:

  • Failing test/log before + passing after
  • Trace/log snippets
  • Screenshot/recording
  • Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

  • Verified scenarios:
  • Edge cases checked:
  • What you did not verify: hard to reproduce on demand

Review Conversations

  • [X ] I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

  • Backward compatible? (Yes/No) - N
  • Config/env changes? (Yes/No) - N
  • Migration needed? (Yes/No) - N
  • If yes, exact upgrade steps:

Failure Recovery (if this breaks)

  • How to disable/revert this change quickly:
  • Files/config to restore:
  • Known bad symptoms reviewers should watch for:

Risks and Mitigations

List only real risks for this PR. Add/remove entries as needed. If none, write None.

  • Risk:
    • Mitigation:

None

Changed files

  • src/agents/skills/refresh.ts (modified, +6/-1)
  • src/auto-reply/reply/session-updates.ts (modified, +18/-12)
  • src/commands/agent.ts (modified, +4/-1)

Code Example

ls ~/.openclaw/workspace/skills/
RAW_BUFFERClick to expand / collapse

Bug Report

Description

The OpenClaw agent context is not loading all available skills from ~/.openclaw/workspace/skills/ directory. Only a subset of skills appear in the initial context under <available_skills>, causing agents to be unaware of existing skills.

Steps to Reproduce

  1. Create multiple skills in ~/.openclaw/workspace/skills/
  2. Start an agent session
  3. Check the <available_skills> section in agent context
  4. Compare with actual directory contents: ls ~/.openclaw/workspace/skills/

Expected Behavior

All skills with valid SKILL.md files in the workspace skills directory should be loaded and listed in the agent's initial context.

Actual Behavior

Only a partial subset of skills are loaded. In my case:

Loaded in context (partial list):

  • design-md
  • react-components
  • shadcn-ui
  • asc
  • astro-mcp
  • etc.

Missing from context but present in filesystem:

  • colegio-vizcaya
  • alexia
  • athletic-club
  • bob-bizkaia
  • cafeterapp
  • irakai-facturas
  • irakai-sync
  • myfooderplan-build
  • whatsapp
  • etc.

Impact

Agents are unaware of available skills, leading to:

  • Manual directory scanning required (ls ~/.openclaw/workspace/skills/)
  • Poor user experience when asking about available tools
  • Inconsistent skill discovery

Environment

  • OpenClaw 2026.3.8 (3caab92)
  • macOS (Darwin 25.3.0 arm64)
  • Runtime: agent=main
  • All missing skills have valid SKILL.md files

Workaround

Manually scan the skills directory when needed:

ls ~/.openclaw/workspace/skills/

Suggestion

The skill loading mechanism should:

  1. Scan all subdirectories in ~/.openclaw/workspace/skills/
  2. Validate each has a SKILL.md file
  3. Load descriptions into agent context
  4. Or provide a dynamic skill discovery command

extent analysis

Problem Summary

The agent’s start‑up routine only reads a subset of the skill directories under ~/.openclaw/workspace/skills/. The loader stops after the first n entries (or only reads the first level that matches a hard‑coded pattern), so many valid skills that contain a SKILL.md file never make it into <available_skills>.

Root Cause Analysis

Typical causes for this behaviour are:

  1. Non‑recursive glob / limited depth – e.g. Path.glob("*") followed by a break after the first match, or a pattern like */SKILL.md that only matches one level.
  2. Caching / stale manifest – a JSON/YAML manifest is built once and never refreshed when new directories appear.
  3. Hidden‑file filtering – the loader may ignore directories that start with a dot or that are not alphabetically first.
  4. Error swallowing – an exception while reading a particular SKILL.md aborts the whole loop, leaving the rest unprocessed.

The fix is to replace the current loader with a robust, fully‑recursive scan that always validates the presence of SKILL.md, logs failures, and updates the agent context.

Fix Plan

Below is a minimal, production‑ready patch (Python‑ish, but the same ideas apply to Node/Go).

1. Centralise the loader

Create/replace openclaw/skill_loader.py:

import json
import logging
from pathlib import Path
from typing import Dict, List

LOGGER = logging.getLogger("openclaw.skill_loader")

SKILLS_ROOT = Path.home() / ".openclaw" / "workspace" / "skills"
SKILL_META = "SKILL.md"


def _read_skill_meta(skill_dir: Path) -> str:
    """Return the raw markdown description or an empty string on error."""
    try:
        return (skill_dir / SKILL_META).read_text(encoding="utf-8")
    except Exception as exc:          # pragma: no cover – defensive
        LOGGER.warning("Failed to read %s: %s", skill_dir,

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ssr#installation#tensor shape#autograd error#chain error#conversation history#tool integration#LLM response#prompt template

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING