OpenClaw Config Safety v2

Validate, normalize, export, and import openclaw.json configs safely with automatic backups and schema checks before applying changes or upgrades.

This package appears to implement a sensible config validation and import/export workflow, but there are important things to check before installing or running it: - Verify dependencies yourself: the code and scripts assume the openclaw CLI is available (or set via OPENCLAW_BIN), the `pass` tool is available for import credential resolution, and the shell validator uses `jq`. The registry metadata does not declare these — confirm they exist and are the versions you expect. - Inspect resolve-refs.js (not shown in full here) to confirm how it invokes `pass` and whether it logs or transmits resolved secrets. The design claims it will not print secret values, but review to be sure. - Back up your existing ~/.openclaw/openclaw.json before using the wizard or the validator (the docs already advise this). Even though the tool creates backups, manual backups are prudent. - Treat exported tokens as containing credential reference names only (mrconf:v1 tokens do not include actual keys). Ensure destination machines have matching env vars or pass entries. - If you do not fully trust the source owner (unknown homepage, owner id only), consider running the scripts in a restricted environment (container or VM) and audit the code paths that call external binaries before giving it access to your real OpenClaw installation and secrets. If you want, I can (a) list exact files/lines that invoke external binaries (openclaw, pass, jq, child_process.exec), (b) extract the resolve-refs implementation for a focused review, or (c) suggest a minimal checklist to run the tool safely in a sandbox first.

Type: OpenClaw Skill Name: openclaw-config-safety Version: 1.0.0 The bundle provides a comprehensive utility for safely managing, validating, and normalizing OpenClaw configurations (openclaw.json). It features a 'config token' system for sharing configurations using environment variable placeholders (${REF}) rather than actual secrets, which are resolved locally via process.env or the 'pass' utility. While the code uses high-risk functions like execSync (in src/resolve-refs.js and src/doctor-check.js), it employs strict regex validation (REF_REGEX) to prevent command injection and includes explicit logic to avoid logging or exporting sensitive credential values. The behavior is entirely consistent with the stated purpose of preventing gateway crashes due to schema drift.