Bug type
CLI / Skill parsing
Summary
When a SKILL.md defines requires.config using the object format (with path, access, purpose properties), the openclaw skills info command incorrectly serializes the config requirement as "[object Object]", and the skill is marked as eligible: false / blocked even though the config file exists and is readable.
Reproduction
- Create or install any skill with a
requires.config entry in object format:
---
name: example-skill
metadata:
openclaw:
requires:
config:
- path: "~/.openclaw/openclaw.json"
access: "read"
purpose: "读取插件配置路径"
---
- Run
openclaw skills info example-skill --agent main --json
Actual behavior
{
"name": "example-skill",
"eligible": false,
"requirements": {
"config": ["[object Object]"]
},
"missing": {
"config": ["[object Object]"]
},
"configChecks": [
{
"path": "[object Object]",
"satisfied": false
}
]
}
The skill shows as blocked in the UI / CLI.
Expected behavior
The config requirement should be parsed as an object with path, access, and purpose properties, and the path check should validate correctly against the filesystem.
Root cause analysis
Looking at the source code:
src/shared/frontmatter.ts — resolveOpenClawManifestRequires() calls normalizeStringList(requiresRaw.config)
src/shared/string-normalization.ts — normalizeStringEntries() uses String(entry) which converts objects to "[object Object]"
src/shared/requirements.ts — Requirements.config is typed as string[], not supporting objects
The config field in requires supports object format per the documentation/schema, but the normalization and type definitions only handle string values.
Environment
- OpenClaw version:
2026.5.7 (eeef486)
- OS: Ubuntu 26.04 LTS
- Install mode: npm global
Workaround
None known. The skill still functions correctly at runtime (the plugin loads via npm), but the status display and eligibility check are broken.
Related
openclaw doctor also reports this skill as having missing requirements due to the same bug.
Bug type
CLI / Skill parsing
Summary
When a SKILL.md defines
requires.configusing the object format (withpath,access,purposeproperties), theopenclaw skills infocommand incorrectly serializes the config requirement as"[object Object]", and the skill is marked aseligible: false/blockedeven though the config file exists and is readable.Reproduction
requires.configentry in object format:openclaw skills info example-skill --agent main --jsonActual behavior
{ "name": "example-skill", "eligible": false, "requirements": { "config": ["[object Object]"] }, "missing": { "config": ["[object Object]"] }, "configChecks": [ { "path": "[object Object]", "satisfied": false } ] }The skill shows as
blockedin the UI / CLI.Expected behavior
The config requirement should be parsed as an object with
path,access, andpurposeproperties, and the path check should validate correctly against the filesystem.Root cause analysis
Looking at the source code:
src/shared/frontmatter.ts—resolveOpenClawManifestRequires()callsnormalizeStringList(requiresRaw.config)src/shared/string-normalization.ts—normalizeStringEntries()usesString(entry)which converts objects to"[object Object]"src/shared/requirements.ts—Requirements.configis typed asstring[], not supporting objectsThe
configfield inrequiressupports object format per the documentation/schema, but the normalization and type definitions only handle string values.Environment
2026.5.7 (eeef486)Workaround
None known. The skill still functions correctly at runtime (the plugin loads via npm), but the status display and eligibility check are broken.
Related
openclaw doctoralso reports this skill as having missing requirements due to the same bug.