Skill flagged — suspicious patterns detected
ClawHub Security flagged this skill as suspicious. Review the scan results before using.
Agent Dashboard
v1.0.4Real-time agent dashboard for OpenClaw. Monitor active tasks, cron job health, issues, and action items from anywhere. Three setup tiers: (1) Zero-config can...
⭐ 0· 936·5 current·5 all-time
byTahseen-ur Rahman@tahseen137
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
OpenClaw
Suspicious
high confidencePurpose & Capability
The skill claims no required env vars or binaries in registry metadata, but SKILL.md and assets require SUPABASE_URL and SUPABASE_ANON_KEY for Tier 3 and CLI tools (gh, vercel) for Tier 2/3 deployment. Requiring a Supabase anon key and deploy CLIs is coherent with a realtime dashboard, but the registry metadata omits those requirements (incoherent).
Instruction Scope
Runtime instructions restrict data collection to OpenClaw APIs (cron list, sessions_list) which fits the stated purpose. However the skill also instructs pushing state to an external Supabase project (Tier 3) and to publish files to GitHub Pages/Vercel (Tier 2/3). The README claims 'All data stays on your machine' for Tier 1 but Tier 2/3 explicitly send dashboard JSON to external hosts — this distinction is not emphasized in metadata and could be misleading to non-technical users.
Install Mechanism
There is no install spec (instruction-only) and one small helper script is included. No remote downloads or archive extraction occur during install. This is low-risk from an installation mechanism perspective.
Credentials
The skill requires SUPABASE_URL and SUPABASE_ANON_KEY in its instructions and in assets/push-dashboard.sh but the registry lists no required env vars or primary credential — that's an important omission. Asking for the Supabase anon key is proportionate for a realtime dashboard, but the SQL policies provided grant anon read and anon update privileges on the dashboard_state table with broad USING/WITH CHECK (true), which means the anon key can overwrite the dashboard row. The skill also assumes users will run gh/vercel CLI commands but doesn't declare those binaries as required.
Persistence & Privilege
The skill is not forced-always and does not request system-wide modifications. However it instructs creation of a recurring cron job and the agent can be asked to push updates (real-time pushes) autonomously — combine that with external endpoints and credentials (Tier 3) and the agent can send operational state off-host when invoked. This is expected behavior for a dashboard but worth considering.
What to consider before installing
This skill appears to implement a plausible dashboard, but there are some mismatches you should address before installing:
- The registry metadata declares no required env vars or binaries, but Tier 3 requires SUPABASE_URL and SUPABASE_ANON_KEY and Tier 2/3 expect gh and vercel CLIs; verify and supply only the minimal values you trust.
- SUPABASE_ANON_KEY is used (and promoted as safe), which is reasonable for a public client, but the provided SQL policy allows anon updates to the dashboard table; anyone with the anon key (or who can access your public client) could overwrite the dashboard row. If you deploy to a public Supabase project, consider tightening RLS to limit updates (e.g., WITH CHECK id = 'main' and/or additional checks) or serve pushes from a trusted server-side key with stricter scope.
- If you want to avoid sending data off-host, use Tier 1 (canvas) only; Tier 2/3 explicitly push data externally. The SKILL.md wording can be confusing on this point.
- Confirm you trust the source (no homepage provided) before providing credentials or deploying public pages. Ask the publisher to update registry metadata to list required env vars and CLIs so you can make an informed decision.
If you plan to use Tier 3, review the SQL and push script and consider: (1) creating RLS rules that constrain updates very narrowly, (2) using a scoped server-side endpoint that validates payloads, or (3) keeping the project private and limiting who can read the anon key. If you are unsure, prefer Tier 1 (zero-config) or review the code offline first.Like a lobster shell, security has layers — review code before you run it.
latestvk972fxjxd26t9phm7hg57bv4y5818r1e
License
MIT-0
Free to use, modify, and redistribute. No attribution required.
