ClawHub

Unraid CLI

v0.4.0

TypeScript CLI for Unraid Server GraphQL API. 12 command groups for system, arrays, disks, containers, VMs, shares, logs, and diagnostics. Built for humans a...

⭐ 0· 126·0 current·0 all-time
byIngo@ingodibella

Install

OpenClaw Prompt Flow

Install with OpenClaw

Best for remote or guided setup. Copy the exact prompt, then paste it into OpenClaw for ingodibella/unraid-cli.

Previewing Install & Setup.
Prompt PreviewInstall & Setup
Install the skill "Unraid CLI" (ingodibella/unraid-cli) from ClawHub.
Skill page: https://clawhub.ai/ingodibella/unraid-cli
Keep the work scoped to this skill only.
After install, inspect the skill metadata and help me finish setup.
Required env vars: UNRAID_HOST, UNRAID_API_KEY
Required binaries: ucli
Use only the metadata you can verify from ClawHub; do not invent missing requirements.
Ask before making any broader environment changes.

Command Line

CLI Commands

Use the direct CLI path if you want to install manually and keep every step visible.

OpenClaw CLI

Bare skill slug

openclaw skills install unraid-cli

ClawHub CLI

Package manager switcher

npx clawhub@latest install unraid-cli
Security Scan
VirusTotalVirusTotal
Benign
View report →
OpenClawOpenClaw
Benign
high confidence
✓
Purpose & Capability
Name, description, required binaries (ucli), and required env vars (UNRAID_HOST, UNRAID_API_KEY) match a CLI that talks to an Unraid GraphQL API. The install step (npm package unraid-cli producing ucli) is appropriate for this purpose.
✓
Instruction Scope
SKILL.md only instructs the agent to run ucli commands, use --output json/--quiet, and reference the CLI config path (~/.config/ucli/config.yaml). It does not ask the agent to read unrelated files, exfiltrate data, or call unexpected endpoints. (The SKILL.md content is duplicated in places, but that is a documentation quality issue rather than a security mismatch.)
ℹ
Install Mechanism
Installation is via npm (package: unraid-cli) which is a typical delivery for a Node CLI. This is a moderate-risk install mechanism because npm packages execute code on install/run; the skill bundle itself contains no package source to scan, so the marketplace static scanner could not analyze the actual runtime code that will be installed.
✓
Credentials
The skill requires only UNRAID_HOST and UNRAID_API_KEY which are exactly the credentials expected for accessing an Unraid server API. No unrelated secrets or system credentials are requested.
✓
Persistence & Privilege
The skill is not always-enabled (always: false), is user-invocable, and does not request system-wide configuration changes or access to other skills' credentials. Agent autonomous invocation is allowed but is the platform default and not in itself an extra privilege.
Assessment
This skill appears to be what it says: a thin wrapper CLI for Unraid that needs the Unraid host and an API key. Before installing, verify the npm package and GitHub repository (owner, publish history, recent activity) to reduce supply-chain risk. Because the marketplace entry is instruction-only, the scanner could not review the actual npm package code — consider inspecting the package source or installing in an isolated/test environment first. Restrict the API key's privileges and lifetime where possible, prefer profiles or per-job --api-key usage rather than broad environment variables, and test read-only workflows before enabling destructive commands (use the SKILL.md guardrails: prefer read-only, require --yes only when deliberate). Also watch for typosquatted package names when running npm install -g.

Like a lobster shell, security has layers — review code before you run it.

Runtime requirements

🖥️ Clawdis
Binsucli
EnvUNRAID_HOST, UNRAID_API_KEY

Install

Install unraid-cli (npm)
Bins: ucli
npm i -g unraid-cli
latestvk97dhr333qxwqm02n9tnzmkbxs83zw30
126downloads
0stars
5versions
Updated 3w ago
v0.4.0
MIT-0
Ingo@ingodibella
latest
Download

ucli agent guide

CLI: ucli [global flags] <group> <command> [args...]

Recommended defaults

ucli --output json --quiet <group> <command>
  • --output json for machine-readable output
  • --quiet to suppress decorative text
  • --fields to shrink payloads
  • --filter and --sort to shape data before it hits your context

Guardrails

  • Prefer read-only commands first. Inspect before acting.
  • Use --yes only in deliberate automation paths, never speculatively.
  • Pair destructive actions with explicit identifiers. No fuzzy matching in the shell.
  • Re-fetch state after any mutation. Do not trust a prior cache.
  • Treat exit code 0 as success. Non-zero: capture stderr, retry only on transient failures.

Command groups

GroupTypical use
systeminfo, health, status, resources, uptime
arraystatus, devices, parity, parity-check actions
disksInventory, SMART, temp, usage, mount
containerslist, inspect, logs, stats, lifecycle actions
notificationslist, latest, get, create, archive
vmslist, inspect, lifecycle actions
shareslist, get, usage
logslist, get, system, tail, search
serviceslist, get, status
networkInterfaces, status
schemaAPI introspection
diagnosticsping, latency, env, doctor

Workflow: health check

ucli system info --output json --quiet
ucli system health --output json --quiet
ucli array status --output json --quiet
ucli services status --output json --quiet
  1. Fetch each separately. Fail fast on non-zero exits.
  2. Summarize array state, service state, resource pressure, warnings.
  3. Only pull logs if the snapshot shows trouble.

Workflow: container management

# list running
ucli containers list --output json --quiet --fields id,names,state,status --sort names:asc

# inspect one
ucli containers inspect <id> --output json --quiet

# restart
ucli containers restart <id> --yes --output json --quiet
  1. Resolve target by id or names.
  2. Inspect current state.
  3. Execute with --yes when confirmation would block automation.
  4. Re-read status after mutation.

Anti-patterns

  • Don't parse human-readable output. Always use --output json.
  • Don't assume partial success from human-readable text. Check exit codes.
  • Don't retry on non-transient errors (auth, bad arguments, missing resources).
  • Don't skip --fields on large result sets. Token waste adds up fast.
  • Don't chain mutations without re-fetching state between them.
  • Don't use --force unless you understand exactly what it skips.

Configuration

Default config path: ~/.config/ucli/config.yaml

default_profile: lab
profiles:
  lab:
    host: http://192.168.1.10:7777
    apiKey: YOUR_API_KEY
    output: json
    timeout: 30

Prefer --host and --api-key explicitly for isolated jobs, --profile <name> for stable environments.

ucli agent guide

CLI: ucli [global flags] <group> <command> [args...]

Recommended defaults

ucli --output json --quiet <group> <command>
  • --output json for machine-readable output
  • --quiet to suppress decorative text
  • --fields to shrink payloads
  • --filter and --sort to shape data before it hits your context

Guardrails

  • Prefer read-only commands first. Inspect before acting.
  • Use --yes only in deliberate automation paths, never speculatively.
  • Pair destructive actions with explicit identifiers. No fuzzy matching in the shell.
  • Re-fetch state after any mutation. Do not trust a prior cache.
  • Treat exit code 0 as success. Non-zero: capture stderr, retry only on transient failures.

Command groups

GroupTypical use
systeminfo, health, status, resources, uptime
arraystatus, devices, parity, parity-check actions
disksInventory, SMART, temp, usage, mount
containerslist, inspect, logs, stats, lifecycle actions
notificationslist, latest, get, create, archive
vmslist, inspect, lifecycle actions
shareslist, get, usage
logslist, get, system, tail, search
serviceslist, get, status
networkInterfaces, status
schemaAPI introspection
diagnosticsping, latency, env, doctor

Workflow: health check

ucli system info --output json --quiet
ucli system health --output json --quiet
ucli array status --output json --quiet
ucli services status --output json --quiet
  1. Fetch each separately. Fail fast on non-zero exits.
  2. Summarize array state, service state, resource pressure, warnings.
  3. Only pull logs if the snapshot shows trouble.

Workflow: container management

# list running
ucli containers list --output json --quiet --fields id,names,state,status --sort names:asc

# inspect one
ucli containers inspect <id> --output json --quiet

# restart
ucli containers restart <id> --yes --output json --quiet
  1. Resolve target by id or names.
  2. Inspect current state.
  3. Execute with --yes when confirmation would block automation.
  4. Re-read status after mutation.

Anti-patterns

  • Don't parse human-readable output. Always use --output json.
  • Don't assume partial success from human-readable text. Check exit codes.
  • Don't retry on non-transient errors (auth, bad arguments, missing resources).
  • Don't skip --fields on large result sets. Token waste adds up fast.
  • Don't chain mutations without re-fetching state between them.
  • Don't use --force unless you understand exactly what it skips.

Configuration

Default config path: ~/.config/ucli/config.yaml

default_profile: lab
profiles:
  lab:
    host: http://192.168.1.10:7777
    apiKey: YOUR_API_KEY
    output: json
    timeout: 30

Prefer --host and --api-key explicitly for isolated jobs, --profile <name> for stable environments.

Comments

Loading comments...