Bug type
Behavior bug (incorrect output/state without crash)
Summary
Setting skills.entries.<key>.enabled: true in config does not force-enable a skill when its requires.bins condition is unmet. This is asymmetric with enabled: false, which force-disables a skill regardless of whether its requirements are satisfied.
Steps to reproduce
- A bundled skill has
requires: { bins: ["some-cli"] } in its SKILL.md frontmatter
- The binary is available inside the sandbox container but NOT on the gateway host's PATH
- Set
skills.entries.<skill-key>.enabled: true in openclaw.json
- Restart the gateway
Expected behavior
The skill is force-enabled and available to the agent, symmetric with how enabled: false force-disables regardless of requirements.
Actual behavior
The skill remains unavailable. shouldIncludeSkill() in src/agents/skills/config.ts checks enabled === false for early return (L80-82) but falls through to evaluateRuntimeEligibility() unconditionally, which rejects the skill because hasBinary() only checks the gateway host's PATH.
OpenClaw version
2026.3.1
Operating system
Linux (Amazon Linux 2023, gateway on EC2)
Install method
Build from source
Logs, screenshots, and evidence
Relevant code in src/agents/skills/config.ts:
// L80-82: enabled: false is respected as a force-disable
if (skillConfig?.enabled === false) {
return false;
}
// L86-101: but enabled: true falls through to runtime eligibility check
return evaluateRuntimeEligibility({
// ...
requires: entry.metadata?.requires,
hasBin: hasBinary,
// ...
});
Impact and severity
- Affected: Any deployment where a skill's binary is available inside the sandbox (e.g., via a sidecar proxy) but not installed on the gateway host
- Severity: Medium (workaround exists: place a dummy binary on the host PATH)
- Frequency: 100% reproducible
- Consequence: Users cannot opt-in to skills without installing binaries on the host, even when the sandbox already has access
Additional information
- Related: Discussion #508 (skill execution on paired nodes) shares the root cause that
hasBinary() only inspects the gateway host
- The fix would be a small change to
shouldIncludeSkill(): if skillConfig?.enabled === true, skip evaluateRuntimeEligibility() and return true
- This preserves backward compatibility —
enabled defaults to undefined (not true), so existing behavior is unchanged
✍️ Author: Claude Code with @carrotRakko (AI-written, human-approved)
Bug type
Behavior bug (incorrect output/state without crash)
Summary
Setting
skills.entries.<key>.enabled: truein config does not force-enable a skill when itsrequires.binscondition is unmet. This is asymmetric withenabled: false, which force-disables a skill regardless of whether its requirements are satisfied.Steps to reproduce
requires: { bins: ["some-cli"] }in its SKILL.md frontmatterskills.entries.<skill-key>.enabled: trueinopenclaw.jsonExpected behavior
The skill is force-enabled and available to the agent, symmetric with how
enabled: falseforce-disables regardless of requirements.Actual behavior
The skill remains unavailable.
shouldIncludeSkill()insrc/agents/skills/config.tschecksenabled === falsefor early return (L80-82) but falls through toevaluateRuntimeEligibility()unconditionally, which rejects the skill becausehasBinary()only checks the gateway host's PATH.OpenClaw version
2026.3.1
Operating system
Linux (Amazon Linux 2023, gateway on EC2)
Install method
Build from source
Logs, screenshots, and evidence
Relevant code in
src/agents/skills/config.ts:Impact and severity
Additional information
hasBinary()only inspects the gateway hostshouldIncludeSkill(): ifskillConfig?.enabled === true, skipevaluateRuntimeEligibility()and returntrueenableddefaults toundefined(nottrue), so existing behavior is unchanged✍️ Author: Claude Code with @carrotRakko (AI-written, human-approved)