Back to plugin
Pluginv0.1.0
ClawScan security
Bricks OpenClaw Plugin · ClawHub's context-aware review of the artifact, metadata, and declared behavior.
Scanner verdict
SuspiciousApr 23, 2026, 8:08 AM
- Verdict
- suspicious
- Confidence
- medium
- Model
- gpt-5-mini
- Summary
- The plugin's code largely matches its stated purpose (a Bricks pull-only OpenClaw channel) but registry metadata omits required configuration, the runtime persists chat state to disk, and the code decodes JWT claims without verifying signatures — these inconsistencies warrant caution before installing.
- Guidance
- This plugin appears to implement the described Bricks pull-only channel, but there are a few things to check before installing: - Required credentials are missing from the registry metadata: ensure you supply BRICKS_BASE_URL, BRICKS_PLUGIN_ID, and BRICKS_PLATFORM_TOKEN when configuring the plugin. The SKILL.md and openclaw.plugin.json show these are required. - Treat BRICKS_PLATFORM_TOKEN as sensitive. The plugin decodes the JWT payload to read claims but does not verify the token signature; do not install unless you trust the issuer of that token and understand the token will be used to derive a user/account id. - The runner persists state to ~/.bricks/node_openclaw_plugin_state.json by default (processed event IDs, mapping tables, and reply text). If this data is sensitive in your environment, change the state file path or secure its permissions. - The plugin will open long-lived connections to the configured BRICKS_BASE_URL and will post/patch messages to that service. Verify the base URL points to a trusted platform and that the token has appropriate scopes/expiry. - If in a stricter environment, review the included built JS files (they are present in the package) and consider building from source or auditing the package contents and file permissions prior to production use. If you want a cleaner assurance: ask the publisher to update registry metadata to declare the required env vars/credentials, and consider asking for JWT signature verification to be added or confirm that token provenance/trust is handled by your provisioning process.
Review Dimensions
- Purpose & Capability
- noteName/description and the code align: this is a Bricks channel plugin that polls a Bricks platform API, ACKs events, and creates/patches messages. However the registry metadata declared no required env vars/credentials while the plugin actually requires BRICKS_BASE_URL, BRICKS_PLUGIN_ID, and BRICKS_PLATFORM_TOKEN (see openclaw.plugin.json and SKILL.md). That metadata mismatch is an incoherence.
- Instruction Scope
- noteSKILL.md instructions correspond to the code (install via openclaw, then configure BRICKS_* values). The runtime will open persistent connections to the user-provided BRICKS_BASE_URL, poll/listen for events, hand inbound messages to OpenClaw, and send assistant output back to the platform. Note: the code decodes JWT payloads to read claims but does not perform signature verification — it trusts the token's claims for deriving tokenUserId and basic validation (typ, pluginId, userId, exp). Also the runtime persists reply text and mappings to a local state file under the user's home directory, which can contain user-visible reply text and mapping data.
- Install Mechanism
- okNo external download/install script in the skill package; distribution is intended via ClawHub/npm and the README/SKILL.md describe standard openclaw plugin install flows. The package contains built JS artifacts — no remote URLs or installers that fetch arbitrary code during install.
- Credentials
- concernThe plugin legitimately requires three sensitive values (BRICKS_BASE_URL, BRICKS_PLUGIN_ID, BRICKS_PLATFORM_TOKEN) to operate. Those are proportional to its purpose, but the skill registry metadata incorrectly lists none as required — this mismatch could cause users to miss that they must provide a secret token. Additionally, the plugin reads optional OPENCLAW_PLUGIN_* env vars for tuning. The BRICKS_PLATFORM_TOKEN is treated as a JWT and its claims are parsed without signature verification, meaning the code trusts the token payload values (e.g., userId) solely based on the token contents.
- Persistence & Privilege
- noteThe plugin writes a state file by default to ~/.bricks/node_openclaw_plugin_state.json and persists processed event ids, clientToken->message mappings and accumulated reply text — this is normal for a long-lived runner but does mean sensitive conversation text and mapping data are stored on disk. The skill is not marked always:true and does not modify other skills; it will run as part of the OpenClaw gateway lifecycle and open long-lived SSE/HTTP connections.
