#23413: Skills: gate remote eligibility expansion behind explicit opt-in

## Summary Describe the problem and fix in 2–5 bullets: - Problem: remote macOS node presence could automatically expand skills eligibility (including macOS-only skills) without explicit user opt-in. - Why it matters: node pairing is an admin surface; automatic expansion broadens reachable capability unexpectedly. - What changed: added `skills.allowRemoteEligibilityExpansion` (default `false`) and gated all remote-skill eligibility expansion behind this flag. - What did NOT change (scope boundary): node pairing, node command permissions, and base local skill eligibility logic. ## Change Type (select all) - [x] Bug fix - [ ] Feature - [ ] Refactor - [x] Docs - [x] Security hardening - [ ] Chore/infra ## Scope (select all touched areas) - [ ] Gateway / orchestration - [x] Skills / tool execution - [ ] Auth / tokens - [ ] Memory / storage - [ ] Integrations - [x] API / contracts - [ ] UI / DX - [ ] CI/CD / infra ## Linked Issue/PR - Closes # - Related # ## User-visible / Behavior Changes Remote-node skill eligibility expansion is now disabled by default and only enabled when `skills.allowRemoteEligibilityExpansion=true`. ## 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`) - If any `Yes`, explain risk + mitigation: ## Repro + Verification ### Environment - OS: macOS - Runtime/container: Node 22 + pnpm - Model/provider: N/A - Integration/channel (if any): Skills + remote node eligibility - Relevant config (redacted): `skills.allowRemoteEligibilityExpansion` ### Steps 1. Connect/register a remote macOS node with `system.run` capability and probed bins. 2. Observe skills eligibility with default config. 3. Set `skills.allowRemoteEligibilityExpansion=true` and re-check eligibility. ### Expected - Default config: no remote eligibility expansion. - Opt-in config: remote eligibility expansion applies. ### Actual - Matches expected behavior. ## Evidence Attach at least one: - [x] 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: remote eligibility helper behavior (default off + opt-in on), schema parse acceptance/rejection, skill command and gateway skill status tests. - Edge cases checked: disconnected-node cleanup still removes exposed bins; non-boolean config value rejected. - What you did **not** verify: docker live-node end-to-end matrix. ## Compatibility / Migration - Backward compatible? (`No`) - Config/env changes? (`Yes`) - Migration needed? (`Optional`) - If yes, exact upgrade steps: - If you rely on remote nodes to make macOS-only skills eligible, set `skills.allowRemoteEligibilityExpansion=true`. ## Failure Recovery (if this breaks) - How to disable/revert this change quickly: revert this PR or set `skills.allowRemoteEligibilityExpansion=true` to restore prior behavior. - Files/config to restore: `skills` section in `openclaw.json`. - Known bad symptoms reviewers should watch for: expected macOS-only skills no longer appear without explicit opt-in. ## Risks and Mitigations - Risk: existing setups that depended on implicit remote expansion lose that behavior after upgrade. - Mitigation: clear docs + explicit opt-in flag and config schema support. <!-- greptile_comment --> <h3>Greptile Summary</h3> This PR adds `skills.allowRemoteEligibilityExpansion` (default `false`) to gate remote macOS node skill eligibility expansion. Previously, pairing a macOS node would automatically make macOS-only skills eligible without explicit opt-in, which could unexpectedly broaden the attack surface. The change correctly places the security gate in `getRemoteSkillEligibility`, which is the sole function responsible for exposing remote node capabilities to the skill eligibility system. All call sites properly pass the config parameter, tests verify the gating behavior, and documentation clearly explains the breaking change and migration path. <h3>Confidence Score: 5/5</h3> - This PR is safe to merge with minimal risk - it's a focused security hardening change with comprehensive test coverage. - The implementation is straightforward and well-tested. All call sites correctly pass the config parameter. The gate is positioned at exactly the right boundary (getRemoteSkillEligibility), preventing unintended skill eligibility expansion without disrupting bin probing or node management. Tests verify both default and opt-in behavior. Documentation clearly explains the breaking change and migration steps. No logic errors or security issues detected. - No files require special attention _{Last reviewed commit: dfe5560} <!-- greptile_other_comments_section --> <!-- /greptile_comment -->