Back to skill
Skillv0.2.6
ClawScan security
Arpc · ClawHub's context-aware review of the artifact, metadata, and declared behavior.
Scanner verdict
SuspiciousFeb 26, 2026, 4:34 AM
- Verdict
- suspicious
- Confidence
- high
- Model
- gpt-5-mini
- Summary
- The skill's stated purpose (agent messaging/ARP) is plausible, but the runtime instructions perform sensitive actions (curl|bash install from a third-party domain, read OpenClaw gateway tokens and session keys, modify systemd config and write plaintext tokens) that are not declared in the metadata — review the installer and token-handling steps before installing.
- Guidance
- This skill appears to do what it says (agent messaging and an optional OpenClaw bridge) but the runtime steps do sensitive things you should not accept blindly. Before installing: - Do NOT run curl | bash on https://arp.offgrid.ing without reviewing the script. Ask for the installer’s source or a reproducible release (git tag/GitHub release or signed binary) and a checksum. - The bridge requires your OpenClaw gateway token and session key. The skill’s instructions locate these in local config files and session files and will store the token in ~/.config/arpc/config.toml (plain text). Only proceed if you trust the arpc authors and understand that anyone with that token can act on your OpenClaw gateway. - The skill metadata did not declare these env vars/config paths — treat that as a red flag. Ask the publisher to declare required credentials/config paths and to explain why each is needed. - If you must try it, run the installer in a controlled environment (VM/container) first, inspect the installer script and the arpc binary, and avoid reusing sensitive tokens. Prefer manual install from audited releases and rotate your OpenClaw gateway token after testing. - If you administer a multi-user system, be cautious: the installer may attempt systemd/launchd changes requiring elevated privileges.
Review Dimensions
- Purpose & Capability
- concernThe skill's purpose (agent-to-agent messaging and an OpenClaw bridge) reasonably explains needing the arpc binary, the relay URL, and access to an OpenClaw gateway token/session key. However, the registry metadata declares no required env vars or config paths while the instructions explicitly read OPENCLAW_GATEWAY_TOKEN and multiple OpenClaw config/session files (~/.openclaw, ~/.clawdbot). This mismatch (undeclared sensitive inputs) is an incoherence and should be justified or fixed.
- Instruction Scope
- concernSKILL.md instructs the agent to: run an installer via curl | bash from https://arp.offgrid.ing, search multiple local config files for the OpenClaw gateway token, extract session keys from session files (~/.openclaw/agents/.../*.jsonl), write plaintext tokens to ~/.config/arpc/config.toml, and optionally alter systemd/launchd service files. Those actions access and persist sensitive credentials and modify system service configuration — they go beyond merely 'calling arpc' and must be explicitly declared and audited.
- Install Mechanism
- concernThere is no formal install spec in the registry. The instructions tell users to run curl -fsSL https://arp.offgrid.ing/install.sh | bash which downloads and executes a script from a non-standard domain (not a well-known, transparently-hosted release like GitHub releases). Piping a remote script to a shell is high risk; the skill provides no checksum, provenance, or content of the installer to verify.
- Credentials
- concernRegistry metadata lists no required env vars or config paths, yet the instructions explicitly read OPENCLAW_GATEWAY_TOKEN (env) and multiple OpenClaw config files to extract a gateway token and session key. These variables/paths are sensitive (auth token, session identifiers) and should have been declared as required. The skill will persist the token in plaintext config (~/.config/arpc/config.toml) per its own notes.
- Persistence & Privilege
- noteThe skill does not request 'always:true' and is not inherently persistent. It does, however, instruct installing a daemon, writing config under ~/.config/arpc (including tokens), and potentially editing systemd service files. Writing its own config and starting a daemon is expected for a messaging service, but the instructions to modify systemd units and store gateway tokens in plaintext raise privilege and persistence considerations that should be reviewed.