Claw Sync
WarnAudited by ClawScan on May 10, 2026.
Overview
Claw Sync appears to be a real backup tool, but it can upload broad private OpenClaw data and has unsafe or under-disclosed sync, restore, and auto-sync behavior.
Install only if you are comfortable backing up OpenClaw memory, profile, rules, tool configs, daily logs, and skills to a private repository. Use a dedicated empty private repo and a fine-grained token, run /sync --dry-run first, audit your skills directory for secrets, avoid /restore --force unless necessary, and do not enable the cron/auto-sync setup unless you want periodic background uploads.
Findings (7)
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.
A malicious or copied repository URL could cause local shell commands to run when syncing.
The repository URL and token are loaded from local configuration and interpolated into a shell command string; URL validation checks host/protocol but does not shell-escape the repository path.
const repoUrl = repo.replace('https://', `https://${token}@`); ... safeExec(`git push ${repoUrl} HEAD:main --force`, { stdio: 'pipe' });Use only a verified private repository URL. The maintainer should replace execSync string commands with spawn/execFile argument arrays and strictly validate repository path characters.
A misconfigured backup repository could lose existing contents or history.
The sync operation force-pushes to the configured repository's main branch, which can overwrite remote branch history if BACKUP_REPO points at an existing or wrong repository.
safeExec(`git push ${repoUrl} HEAD:main --force`, { stdio: 'pipe' });Use a dedicated empty private repository only. The maintainer should avoid force-push by default or require an explicit warning/confirmation for destructive remote updates.
Private agent memory, custom skills, and any secrets stored inside skill folders may be persisted to the remote backup repository and its tags.
The implementation copies each skill directory recursively into the sync staging area, without visible filtering for .env files, embedded credentials, git metadata, or other private files inside skills.
fs.cpSync(skillPath, destPath, { recursive: true });Audit the skills directory before syncing, keep the backup repository private, and add explicit denylist/exclusion handling for .env, config, credentials, node_modules, and .git data.
Users may trust the 'secrets never leave' framing and sync more data than they intended.
The documentation makes broad safety claims, but the provided push code recursively copies whole skill folders, so secret files inside those folders may still be included.
## NOT Synced (security) ... - `.env` - Contains secrets ... - 🔒 **Secure** - No config files synced, token sanitization
Treat the safety claim as incomplete. The maintainer should either implement recursive secret exclusions or narrow the documentation to exactly what is and is not filtered.
Sensitive memory and skill data could be uploaded periodically in the background after setup.
The setup script creates an enabled recurring agent-turn job that runs the sync script every 12 hours if activated or loaded.
schedule: { kind: "every", everyMs: 12 * 60 * 60 * 1000 }, payload: { kind: "agentTurn", message: "exec: node skills/claw-sync/scripts/push.js" }, enabled: trueDo not enable auto-sync unless you want ongoing background backups. The maintainer should declare this capability prominently and require explicit activation/removal instructions.
Anyone who obtains the token may be able to read or modify the configured backup repository.
A Git provider token with repository contents read/write permission is expected for this backup use case, but it is still a sensitive delegated credential.
# Required permissions: Contents (Read and Write) ... BACKUP_TOKEN=ghp_xxxxxxxxxxxxxxxxxxxx
Use a fine-grained token limited to one dedicated private backup repository, rotate it if exposed, and avoid reusing a broader personal token.
Users may not see the credential and tooling requirements until after reading the skill files.
The registry metadata under-declares the actual Git/token setup and command execution requirements, although the included docs do describe them.
Source: unknown; Homepage: none; Required env vars: none; Primary credential: none; Required binaries: none; No install spec
Publish clear source/homepage metadata and declare the Git/token requirements in registry metadata.