Agent Config Sync
WarnAudited by ClawScan on May 16, 2026.
Overview
This looks like a real multi-agent configuration sync tool, but it asks for persistent authority to auto-propagate high-impact configuration changes, including API-key-related configuration, across agent workspaces with inconsistent safety disclosures.
Install only if you are comfortable letting a master agent modify configuration files and heartbeat/startup behavior across all listed OpenClaw agent workspaces. Before running setup, inspect the registry, run dry-run mode, exclude API keys or other secrets from synced config, and require manual review for any sync that changes agent identity, tools, code, or credentials.
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.
API keys or other secrets embedded in configuration could be copied into other agent workspaces or sync files without a clearly defined secrets policy.
The skill explicitly includes API keys in the synchronization scope, but the registry metadata declares no primary credential or environment variables and the security docs claim no credential access.
**Syncs**: System code · Agent configs (SOUL/IDENTITY/TOOLS) · OpenClaw config · Task configs · API keys
Do not sync real secrets unless the skill is configured to redact them or use vault references; document exactly which credentials may be copied and require explicit user approval for secret-bearing changes.
A user may install or run the skill believing secrets are out of scope when the sync model may in fact move API-key-related configuration.
The README simultaneously says the skill syncs API keys and says it has no credential access, which is an inconsistent safety claim.
**Syncs**: ... Task configs · API keys ... Security ... No network, no API calls, no credential access
Align the security documentation with the actual sync scope: either remove API keys from scope or clearly warn that secret-bearing config may be propagated.
A mistaken or malicious change in the master workspace could propagate to many agents and alter their behavior or configuration.
The heartbeat workflow gives the master agent authority to push configuration changes to all downstream agents through messaging or file writes.
If version mismatch detected → dispatch to all downstream agents: ... sessions_send to each agent (or write pending_sync_<VERSION>_<SHA>.md as fallback)
Add per-sync approval, file allowlists, dry-run previews, and clear rollback instructions before dispatching changes that affect agent configs, tools, code, or secrets.
The skill can keep influencing agents after initial setup, so future heartbeats may apply changes without the user noticing each time.
The setup persists recurring sync behavior by appending instructions to each agent's heartbeat/startup files.
HEARTBEAT.md (append to end) ... 配置同步检查（每次 heartbeat 执行） ... 读取变更摘要，更新 MEMORY.md，删除文件
Require explicit consent before modifying BOOTSTRAP.md or HEARTBEAT.md, mark inserted blocks clearly, and provide a simple disable/uninstall cleanup path.
If an unauthorized process or agent can place or alter pending_sync files in a workspace, another agent may treat the file as authoritative sync input.
The described signature is a plain SHA256 over visible content, which can check consistency but does not authenticate the sender, while pending_sync files are used as instructions to apply changes.
sha256("pending_sync_<VERSION>_" + 变更摘要) ... Receiving agent can verify file integrityUse authenticated signatures or trusted-channel metadata, restrict who can create pending_sync files, and have agents verify sender identity before applying changes.