Summary

• Problem: parseBinProbePayload only handles string[] and stdout formats, but system.which returns Record<string, string> (keys = bin names, values = resolved paths). Array.isArray() returns false for objects → always returns empty [].
• Why it matters: Docker/Linux gateway + remote Mac node setups never recognize remote bins → skills always show "blocked". Not caught earlier because most users run gateway locally on Mac where hasBinary() resolves bins directly without the remote probe path.
• What changed: parseBinProbePayload now extracts Object.keys() from Record-typed bins responses. Exported the function for direct unit testing.
• What did NOT change (scope boundary): system.run fallback path, existing string[] handling, local bin detection, and all other skills logic.

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: Docker gateway + remote Mac node skill resolution

User-visible / Behavior Changes

Skills that were previously shown as "blocked" in Docker gateway + remote Mac node setups will now correctly show as "eligible" when the remote node has the required binaries.

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 (node host) + Linux/Docker (gateway)
• Runtime/container: Docker gateway with remote Mac node connected via WebSocket

Steps

1. Run gateway in Docker container (Linux).
2. Connect a Mac node host: openclaw node run --host <gateway-ip> --port 18789.
3. Node host responds to system.which probe with { bins: { "git": "/usr/bin/git", ... } }.
4. Check skills status in Control UI.

Expected

Skills that require remote bins (e.g., git) should show as "eligible".

Actual

All remote-bin-dependent skills show as "blocked" because parseBinProbePayload returned [].

Evidence

• Failing test/log before + passing after

Root cause trace: parseBinProbePayload line 211 does Array.isArray(parsed.bins) which is false for Record<string, string> objects → falls through to stdout check (also fails) → returns [].

After fix: 10/10 tests pass including 8 new tests covering all three response formats (string[], Record, stdout) and edge cases.

Human Verification (required)

• Verified scenarios: node host probe logs confirm system.which returns Record format; new unit tests validate all three parse paths.
• Edge cases checked: empty bins object, whitespace in bin names, null/undefined input, invalid JSON, payload as second argument.
• What you did not verify: end-to-end Docker gateway restart with the fix (requires image rebuild).

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 this commit; system.run fallback will be used for nodes that don't support system.which.
• Files/config to restore: src/infra/skills-remote.ts
• Known bad symptoms reviewers should watch for: skills showing incorrect eligibility status.

Risks and Mitigations

• Risk: Object.keys() on unexpected payload shapes.
  • Mitigation: guarded by typeof parsed.bins === "object" check; wrapped in try/catch; existing string[] and stdout paths unchanged.

🤖 AI-assisted (fully tested, code understood)