Skill dependency scan/install does not match sandbox runtime, and lacks a control switch

Skill dependency scan/install does not match sandbox runtime, and lacks a control switch

Problem

Skill dependency scanning, missing-dependency detection, and installation are currently performed against the GoClaw runtime container environment. But when an agent actually executes skill scripts with sandbox enabled, the real execution environment becomes the sandbox container.

This creates two problems at once:

1. To make dependency scan/install succeed, the main runtime container may need Python, Node.js, or additional pip/npm/apk packages preinstalled, which increases image/runtime size
2. Even if those dependencies are installed in the main runtime container, sandboxed agents may still not benefit because execution has moved to the sandbox environment

So the current semantic of “scan missing deps -> install deps -> skill becomes usable” is not reliable when sandbox is enabled, and there is no configuration switch to control this behavior.

Verified behavior

The following has been confirmed:

• skill dependency checks run through ScanSkillDeps(...) + CheckSkillDeps(...) in the current GoClaw runtime environment
• install-deps / install-dep directly call pip3 / npm / apk-helper to install into the current runtime container
• API docs and frontend copy both explicitly state that checks target the active GoClaw runtime container, not the host machine
• but if the agent runs with sandbox enabled, actual file tools / shell / script execution happens inside the sandbox container
• so the environment being checked/installed is not necessarily the same environment where the skill will run

Root cause

The current skill dependency system assumes that “check environment = install environment = execution environment”, but that assumption breaks once sandbox is enabled:

• Check environment: GoClaw runtime container
• Install environment: GoClaw runtime container
• Execution environment: sandbox container

At the same time, the system encourages restoring skill usability by installing runtimes or packages into the main runtime container. That increases image/runtime size and maintenance cost, while not necessarily helping sandboxed agents.

Relevant code

• internal/skills/dep_checker.go: CheckSkillDeps uses exec.LookPath, python3, and node to inspect the current environment
• internal/skills/dep_installer.go: InstallDeps / InstallSingleDep directly run pip/npm/apk installs in the current runtime environment
• internal/skills/seeder.go: CheckDepsAsync asynchronously scans deps on startup and archives/activates skills based on that result
• internal/http/skills.go: rescan-deps / install-deps / install-dep expose system-level dependency management
• docs/18-http-api.md: explicitly says packages / runtimes are checked inside the active GoClaw runtime container
• ui/web/src/i18n/locales/zh/skills.json: copy explicitly says host-installed runtimes are not used here
• internal/sandbox/docker.go: sandboxed agents actually run in a separate sandbox container environment
• internal/sandbox/sandbox.go: sandbox config currently has no dedicated switch for skill dependency scan/install scope

Impact

• the main runtime container may grow just to satisfy skill dependency checks
• sandboxed agents may still fail to run skills because sandbox dependencies are missing
• skill status such as active / archived only reflects the main runtime container, not true sandbox executability
• users may incorrectly assume that “dependencies installed successfully” means the skill will also work in sandbox mode

Recommendation

Skill dependency scanning/install should become configurable. At minimum, the system should allow:

1. enabling/disabling automatic dependency scanning
2. enabling/disabling automatic dependency installation
3. choosing the check/install scope:
   • main runtime container only
   • sandbox only
   • both environments
   • for sandbox agents, skip auto-install and only emit warnings
4. exposing a sandbox-specific policy:
   • if dependencies exist only in the main runtime container, do not mark the skill as available to sandboxed agents

At minimum, a clear configuration switch should exist so teams can control whether dependency scan/install happens at all, instead of being pushed to enlarge the main runtime environment just to satisfy this mechanism.

Start by tracing dependency checks and installs through internal/skills/dep_checker.go, dep_installer.go, and seeder.go, then review the HTTP handlers and sandbox configuration in internal/http/skills.go and internal/sandbox/sandbox.go. Compare this with internal/sandbox/docker.go and the documented runtime behavior; done means the chosen scan/install controls and sandbox scope are represented consistently in configuration and behavior.