Skillv1.0.0

ClawScan security

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

Scanner verdict

SuspiciousMar 7, 2026, 2:17 PM

Verdict: suspicious
Confidence: medium
Model: gpt-5-mini
Summary: The skill's scripts and SKILL.md align with a legitimate git-backup purpose, but registry metadata omits required credentials and the scripts include token-handling patterns (embedding tokens in URLs, cron examples with inline tokens) that could expose secrets—review before use.
Guidance: This skill appears to do what it says (backup selected OpenClaw workspace files to a git repo), but there are important cautions: (1) registry metadata incorrectly omits required environment variables—expect to provide a personal access token (GITEE_TOKEN), repo URL (GITEE_REPO), and AGENT_NAME before use; (2) the scripts embed tokens into HTTPS URLs for git clone/push which can expose tokens (process lists, git config) — prefer using git credential helpers, deploy keys, or configuring remotes without embedding tokens; (3) avoid placing tokens inline in cron entries or plaintext files; instead export them from a secure source or use a credential manager; (4) review the scripts yourself (they are plain shell) and test in an isolated account/repo with minimal token scopes (only repo/project create/push as needed) and rotate the token afterward. If you need, ask for a version that uses SSH deploy keys or a credential helper instead of embedding tokens in URLs, and request the registry metadata be corrected to list the required env vars/primary credential.

Review Dimensions

Purpose & Capability: noteName/description and the included scripts (create-repo, setup, backup, watcher) are coherent: they create a repo and push selected workspace files. However the registry metadata declared no required environment variables or primary credential while the SKILL.md and scripts clearly require GITEE_TOKEN, GITEE_REPO, and AGENT_NAME. That mismatch is unexplained and worth caution.
Instruction Scope: concernSKILL.md and scripts limit backups to specific files/dirs and explicitly exclude .env/keys, which is good. But instructions/examples encourage practices that risk credential exposure: embedding personal access tokens into HTTPS clone URLs (AUTH_REPO), and showing an example cron entry that includes GITEE_TOKEN inline. The watcher/daemon and scripts write logs and PID/state files to /tmp and the workspace; they also run network calls to Git hosting APIs. These behaviors are within the backup purpose but include concrete steps that can leak secrets if used as-is.
Install Mechanism: okInstruction-only skill with shell scripts; no install spec or external downloads. This has lower install-time risk because nothing is automatically fetched from arbitrary URLs. The included scripts are plain shell and self-contained.
Credentials: concernThe skill requires a personal access token with repo/projects scope, but the registry metadata lists no required env vars or primary credential—an inconsistency. The number and type of secrets requested (GITEE_TOKEN/GITEE_REPO/AGENT_NAME) are reasonable for a backup skill, but how the token is used (embedded in URLs, suggested inline in cron) increases exposure risk beyond what is necessary.
Persistence & Privilege: okThe skill does not request always:true and is user-invocable. It provides a watcher/daemon and cron examples for persistent backups, which is reasonable for the function. It does not attempt to modify other skills or system-wide agent settings in the provided scripts.