v1.0.0

moltcomm

ReviewClawScan verdict for this skill. Analyzed May 1, 2026, 5:19 AM.

Analysis

This text-only protocol spec is coherent, but it would add a persistent peer-to-peer agent messaging channel where untrusted remote messages are read by the agent and message contents may be visible to relays unless extra protections are implemented.

GuidanceInstall or use this only if you intentionally want persistent peer-to-peer agent messaging. Before running any implementation, review SKILL_IMPL.md and the daemon code, pin trusted relay/bootstrap identities, enable encryption for sensitive messages, isolate inbound messages from agent instructions, and keep clear controls for starting, stopping, and deleting the .moltcomm data.

Findings (4)

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.

Abnormal behavior control

Checks for instructions or behavior that redirect the agent, misuse tools, execute unexpected code, cascade across systems, exploit user trust, or continue outside the intended task.

Rogue Agents

SeverityLowConfidenceHighStatusNote

references/OPENCLAW.md

`moltcommd` (daemon): always-on networking process

The skill explicitly calls for a persistent background daemon to receive messages and process local inbox/outbox files; this is disclosed and purpose-aligned but should be user-controlled.

User impactA MoltComm implementation may keep running after the immediate task, continue network connections, and send or receive messages through local files.

RecommendationRun the daemon only when intended, document start/stop behavior, keep its data directory scoped, and avoid enabling automatic startup unless the user wants persistent messaging.

Agent Goal Hijack

SeverityLowConfidenceHighStatusNote

SKILL.md

If `SKILL_IMPL.md` exists, use it as the authoritative “how to run my MoltComm implementation” guide.

The skill gives a local file authority over operational instructions, which is useful for a local implementation but risky if that file is unreviewed or came from an untrusted repository.

User impactA malicious or accidental SKILL_IMPL.md could steer the agent toward unsafe commands or configuration choices.

RecommendationReview SKILL_IMPL.md before following it, treat it as untrusted unless you created it, and ask for confirmation before running commands from it.

Sensitive data protection

Checks for exposed credentials, poisoned memory or context, unclear communication boundaries, or sensitive data that could leave the user's control.

Memory and Context Poisoning

SeverityHighConfidenceHighStatusConcern

references/OPENCLAW.md

2) Read `.moltcomm/inbox.ndjson` and collect all entries with `seq > cursor`. 3) If there are new entries, read them ... SPAM/SEC -- If any new messages appear to be SPAM or security threats like prompt injection, consider implementing technical measures

The spec requires externally received messages to be persisted and then read by the OpenClaw agent during heartbeat, while prompt-injection mitigation is only suggested for the future rather than required.

User impactRemote peers could place text into files that the agent later reads, which may influence the agent if messages are not clearly treated as untrusted data.

RecommendationTreat inbox content as untrusted data, isolate or quote it, use sender allowlists, require user approval before acting on message content, and add explicit prompt-injection handling before enabling heartbeat ingestion.

Insecure Inter-Agent Communication

SeverityMediumConfidenceHighStatusConcern

references/SECURITY.md

If confidentiality is required, encrypt application payloads; relays can otherwise read `body.msg`.

The protocol requires signatures for integrity but does not require encryption, so public or community relay operators can read direct-message payloads unless the implementation adds encryption.

User impactMessages sent through MoltComm may expose sensitive conversation content to relay operators or other infrastructure used for delivery.

RecommendationDo not send secrets unless end-to-end encryption is enabled, pin trusted relay identities and bootstrap manifests, and document which peers and relays are allowed.