Oganim Deploy
WarnAudited by ClawScan on May 16, 2026.
Overview
This deploy helper is not clearly malicious, but it gives the agent production deployment, database superuser, and account-administration powers without enough declared credential scope or approval guardrails.
Install this only if you control the referenced Vercel/Supabase project and are comfortable giving the agent production deploy, database-admin, and auth-admin abilities. Before use, restrict credentials to the intended project, require explicit approval for production deploys/migrations/account changes, prefer staging or test accounts for Playwright recipes, and pin any setup dependencies.
Findings (5)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
If installed in an environment with these files, the agent could use production deployment and database-admin credentials.
The skill instructs the agent to read local production credentials and use Supabase postgres superuser access, while the registry metadata declares no required credentials or config paths.
VERCEL_TOKEN=$(cat ~/.openclaw/credentials/vercel/token) \ npx vercel deploy --prod --yes ... The runner connects to the Supabase pooler as the `postgres` superuser using credentials from `~/.openclaw/credentials/supabase/credentials.env`.
Declare required credentials explicitly, use least-privilege tokens, scope them to the intended project, and require user confirmation before any production deploy or database migration.
A mistaken or premature agent action could ship broken code or alter a live database.
The documented workflow uses non-interactive production deployment and database migration commands, but does not define an approval gate, staging requirement, rollback plan, or bounded set of safe changes.
npx vercel deploy --prod --yes ... node deploy/run-migration.cjs deploy/migration-stageN-<topic>.sql
Add explicit instructions to ask the user before production deploys or migrations, prefer dry-run/staging verification, and document rollback/recovery steps.
Testing could disrupt customer access or leave account state changed if cleanup fails.
The verification recipe mutates a real customer authentication record and acknowledges that the customer may need a password reset afterward, which can affect live users if run on production.
await fetch(`${cred.SUPABASE_URL}/auth/v1/admin/users/${USER_ID}`, { method: 'PUT' ... body: JSON.stringify({ password: TEMP_PASS }) ... }); ... (After this, the customer must request a password reset to log in again.)Run these recipes only against test accounts or staging projects, require explicit user approval for live-account changes, and add verified cleanup checks.
Running the setup script pulls code from npm into the local test directory.
The setup helper installs Playwright from npm without a pinned version or lockfile. This is aligned with the browser-verification purpose and is not automatic, but it depends on external package provenance.
npm i playwright --no-save
Pin Playwright to a known version and checksum or use a project lockfile if reproducibility is important.
Screenshots from live admin or customer pages could include private data visible to the assistant tooling.
The recipe intentionally moves screenshots into the assistant-readable workspace for image analysis; if screenshots contain CRM or portal data, they may expose sensitive customer information to the analysis tool/context.
cp /tmp/oganim-test/foo.png ~/.openclaw/workspace/foo.png # Then: tool call → image(path=~/.openclaw/workspace/foo.png, prompt="...")
Use redacted screenshots where possible, avoid capturing real customer data, and delete workspace artifacts after review.