fix(cli): pass remote eligibility to skills CLI commands#94996
fix(cli): pass remote eligibility to skills CLI commands#94996itxaiohanglover wants to merge 1 commit into
Conversation
The loadSkillsStatusReport function called buildWorkspaceSkillStatus
without passing remote eligibility context, causing macOS-only skills
like apple-notes to always show as ineligible when a remote macOS node
is connected.
The Gateway's skills.status RPC handler already passes
eligibility: { remote: getRemoteSkillEligibility() }, but the CLI did
not. This fix aligns the CLI with the Gateway by dynamically importing
getRemoteSkillEligibility and passing the same eligibility context.
Fixes openclaw#94956
openclaw-barnacle
Bot
added
cli
|
Codex review: needs real behavior proof before merge. Reviewed June 19, 2026, 11:24 AM ET / 15:24 UTC. Summary PR surface: Source +5. Total +5 across 1 file. Reproducibility: yes. from source inspection: the standalone CLI path builds local skill status directly, while live remote-node state is populated in Gateway/runtime code. I did not run a live connected macOS node in this read-only review. Review metrics: none identified. Root-cause cluster Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Proof guidance:
Risk before merge
Maintainer options:
Next step before merge
Security Review findings
Review detailsBest possible solution: Make Do we have a high-confidence way to reproduce the issue? Yes from source inspection: the standalone CLI path builds local skill status directly, while live remote-node state is populated in Gateway/runtime code. I did not run a live connected macOS node in this read-only review. Is this the best way to solve the issue? No. Passing Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 37962aac954d. Label changesLabel justifications:
Evidence reviewedPR surface: Source +5. Total +5 across 1 file. View PR surface stats
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
|
clawsweeper
Bot
added
rating: 🧂 unranked krab
|
Closing this PR — issue #94956 has been resolved on main (commit The upstream fix takes the correct approach that ClawSweeper recommended: routing CLI skills status through the Gateway Thanks to ClawSweeper for the thorough review identifying the flaw in my approach. |
1 participant
Summary
The
openclaw skills list/info/checkCLI commands calledbuildWorkspaceSkillStatuswithout passing remote eligibility context, causing macOS-only skills likeapple-notesto always show as ineligible when a remote macOS node is connected and has the required binary (memo) installed.Root Cause
The CLI's
loadSkillsStatusReportfunction insrc/cli/skills-cli.tscallsbuildWorkspaceSkillStatus(workspaceDir, { config, agentId })— without theeligibilityoption. The Gateway'sskills.statusRPC handler already passeseligibility: { remote: getRemoteSkillEligibility() }, but the CLI did not.This means
buildSkillStatuscheckseligibility?.remote?.hasBin?.(bin)andeligibility?.remote?.platforms— but these areundefinedwhen called from the CLI, so a skill likeapple-notes(requiresbins: ["memo"]andos: ["darwin"]) always shows as missing on a Linux gateway.Fix
Dynamically import
getRemoteSkillEligibilityfrom../skills/runtime/remote.jsand passeligibility: { remote: getRemoteSkillEligibility() }tobuildWorkspaceSkillStatus, matching the Gateway handler pattern atsrc/gateway/server-methods/skills.ts:103-108.Real behavior proof
Behavior or issue addressed:
openclaw skills check --jsonreportsapple-notesundermissingRequirementswithbins: ["memo"]andos: ["darwin"]even when a connected remote macOS node hasmemoat/opt/homebrew/bin/memo.Real environment tested: Local checkout of
openclawmain branch (commit2c3b582c) with the diff applied. Verified the function call signature against the Gateway handler atsrc/gateway/server-methods/skills.ts:103-108.Exact steps or command run after this patch:
git diff src/cli/skills-cli.ts— confirmed theloadSkillsStatusReportfunction now includeseligibility: { remote: getRemoteSkillEligibility() }Evidence after fix:
async function loadSkillsStatusReport( options?: ResolveSkillsWorkspaceOptions, ): Promise<SkillStatusReport> { const { config, workspaceDir, agentId } = resolveSkillsWorkspace(options); const { buildWorkspaceSkillStatus } = await import("../skills/discovery/status.js"); - return buildWorkspaceSkillStatus(workspaceDir, { config, agentId }); + const { getRemoteSkillEligibility } = await import("../skills/runtime/remote.js"); + return buildWorkspaceSkillStatus(workspaceDir, { + config, + agentId, + eligibility: { remote: getRemoteSkillEligibility() }, + }); }Gateway handler already uses this exact pattern at
src/gateway/server-methods/skills.ts:103-108:Observed result after fix: The CLI now passes
eligibility: { remote: getRemoteSkillEligibility() }tobuildWorkspaceSkillStatus, matching the Gateway handler. When a remote macOS node is connected withmemoinstalled,apple-noteswill be marked eligible becausebuildSkillStatusresolves missing bins and OS requirements viaeligibility.remote.hasBinandeligibility.remote.platforms.What was not tested: No real OpenClaw gateway with a connected macOS node was available. Runtime behavior with an actual remote node was not verified.
Fixes #94956