Skills Setup
ReviewAudited by ClawScan on May 16, 2026.
Overview
This plugin deliberately lets admins run trusted skills’ setup scripts, and the artifacts clearly disclose that this is local code execution with meaningful side effects.
This skill appears coherent and transparent for its purpose. Install it only if you want an admin-controlled way to run installed skills’ setup scripts, and treat each target setup script like any other local shell script: review it first, pass only necessary secrets, and expect it may change files, install dependencies, or contact services.
Publisher note
This release is a plugin-based implementation path for openclaw/openclaw#80213, which tracks skill author-defined setup hooks for running skill-supplied scripts after install/update. Skills Setup intentionally exposes a manual, admin-only `skills.setup` Gateway RPC. Unlike a future core install/update hook, this plugin does not automatically run setup scripts after skill install or update. A caller with `operator.admin` scope must invoke setup for a specific installed skill. The plugin intentionally executes trusted skill-declared local bash setup scripts. This is the purpose of the plugin, and execution is bounded by admin-only access, setup-script path validation, skill-directory containment checks, and a configurable timeout. Version 2026.5.16-1 addresses grouped skill basename collisions. Callers may use group-qualified selectors such as `team/demo`; if a basename-only selector matches multiple grouped installed skills, the plugin rejects the request instead of choosing the first match. Version 2026.5.16-2 tightens setup environment handling. Configured skill env and request env are explicit inputs to the setup process, while caller overrides for execution-context variables such as `HOME`, `PATH`, `SKILL_DIR`, `XDG_CONFIG_HOME`, and `XDG_DATA_HOME` are blocked. Bash startup/control variables, exported bash functions, and loader-injection prefixes such as `BASH_ENV`, `ENV`, `SHELLOPTS`, `BASHOPTS`, `BASH_FUNC_*`, `LD_*`, and `DYLD_*` are also blocked or cleared from the setup process. Environment variables may still intentionally include credentials needed by a trusted setup workflow. Users should pass only narrowly scoped secrets, only to trusted skills, and only after reviewing the target setup script. The plugin intentionally does not record setup completion. Each invocation reruns the declared setup script, so setup scripts must be idempotent and users should invoke setup deliberately.
Findings (3)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
A setup script can make local changes under the agent process user’s permissions, including installing packages, writing files, or calling network services.
The plugin’s main function is to execute local bash scripts from installed skills. This is powerful but clearly disclosed and purpose-aligned.
Runs the declared setup script with `bash`; this is intentional local code execution and is restricted to callers with `operator.admin`.
Only invoke setup for skills you trust, and review the target setup script before running it.
A trusted setup script may need credentials, but any secret you pass can be read or used by that script.
The setup script inherits meaningful local authority and may receive credentials supplied through configuration or request environment variables.
Setup scripts run with the agent process user's local privileges... any allowed secret passed through skill config or request env is available to the setup script.
Use narrowly scoped credentials, avoid passing secrets to untrusted skills, and confirm the caller has appropriate admin authority.
Running setup more than once could duplicate or repeat changes if the target script is not idempotent.
Repeated invocations can repeat side effects such as dependency installation, config writes, or external API calls.
Does not record completion state. Each `skills.setup` invocation reruns the target setup script.
Prefer setup scripts that are safe to rerun, and invoke the RPC deliberately rather than repeatedly.