Pluginv0.1.1

ClawScan security

Guild · ClawHub's context-aware review of the artifact, metadata, and declared behavior.

Scanner verdict

SuspiciousMar 30, 2026, 10:40 PM

Verdict: suspicious
Confidence: medium
Model: gpt-5-mini
Summary: The plugin's code matches its described purpose (Supabase-backed multi-user memory/skills) but the registry metadata omits required configuration/secret usage and the plugin reads gateway env and agent credentials from plugin config—these mismatches and broad access deserve careful review before installing.
Guidance: This plugin appears to implement what it claims (team memory, per-agent auth, auto-recall/auto-capture) and will run inside your OpenClaw gateway with access to configured Supabase. Before installing: 1) Verify and supply a dedicated Supabase instance and set up strict row-level security (RLS) policies as the README explains. 2) Do not store high-privilege keys in places accessible to untrusted users; prefer providing only the minimal anon/public key to the running plugin and keep the service role key offline or only for one-time CLI admin use. 3) Audit openclaw.json (pluginConfig) for any agent credentials — agent auth stored in plugin config means those secrets live in the gateway config (consider using $ENV refs and limiting who can read gateway env/files). 4) Review the code (or run in a staging environment) to confirm auto-capture rules and opt-out behavior meet your privacy requirements — note the plugin will capture inferred facts by default if the opt-out check cannot be read. 5) If you need stronger assurance, run the plugin with least privilege networking (allowlist only your Supabase host) and review Supabase audit logs. If you cannot accept gateway-level env access or storing agent creds in plugin config, treat this plugin as too broad and avoid installing.
Findings: [process_env_reference] expected: resolveEnvRef intentionally reads process.env for $VAR references in plugin config to allow secret injection from the gateway environment. This is expected for a plugin that must access Supabase/service keys, but it does give the plugin access to arbitrary gateway env vars referenced by configuration. [network_fetch_supabase_rest] expected: Code performs fetch() calls to Supabase REST endpoints (auth, rest/v1/*). This is expected and required by the described functionality. [fs_read_session_file] expected: before_compaction reads session transcripts from a sessionFile (node:fs/promises readFile). This matches the SKILL.md claim that it will read pre-compaction transcripts to persist important context. [admin_auth_api_usage] expected: CLI provisioning uses Supabase admin endpoints (/auth/v1/admin/users) and requires a service-role key. This is expected for host-side admin operations, but that key is sensitive and not declared in registry metadata.

Review Dimensions

Purpose & Capability: concernThe skill claims to be a Supabase-backed guild for multi-user agents and the code implements that (Supabase REST calls, per-agent auth, memory/skill tooling). However the registry metadata lists no required env/config even though the code requires pluginConfig.supabaseUrl and pluginConfig.supabaseAnonKey (and optionally a supabaseServiceKey or SUPABASE_SERVICE_ROLE_KEY for admin CLI). The omission of those requirements in metadata is an incoherence that could confuse install-time checks and permissions reviews.
Instruction Scope: noteSKILL.md explicitly states the plugin will access the gateway env vars, session transcripts, and user messages; the code implements hooks that read session files, scan user messages (auto-capture), and inject user/company/role context (auto-recall). This is coherent with the description. Two points to note: (1) resolveEnvRef will read arbitrary process.env entries referenced in plugin config (gateway-level env), and (2) auto-capture defaults to capturing if the opt-out check fails (isAutoCaptureDisabled returns false on error), which can cause facts to be stored when the opt-out flag can't be read.
Install Mechanism: okThere is no install spec in the registry (instruction-only), which is lower-risk from an install-supply perspective. However the package includes executable JS code that will run inside the OpenClaw gateway—this is expected for a plugin but means the code will execute with gateway privileges and network access to the configured Supabase URL.
Credentials: concernThe plugin requires access to Supabase credentials (supabaseUrl, supabaseAnonKey) and for admin operations a service role key (supabaseServiceKey or SUPABASE_SERVICE_ROLE_KEY). Those sensitive values are not declared in the metadata. The plugin also supports placing per-agent credentials in the plugin config (agents.*.email/password/jwt) and resolves $ENV references against process.env, giving it read access to gateway environment variables. Storing agent auth in openclaw plugin config or giving the plugin access to gateway env secrets increases the attack surface and should be justified/limited.
Persistence & Privilege: okThe skill does not set always:true and does not request permanent platform-wide privileges. It uses in-process caches and writes only to the configured Supabase instance. It does not modify other skills in the package. Still, because it runs inside the gateway, it has access to the gateway environment (by design) — treat gateway env as sensitive.