Olvid Channel
ReviewAudited by ClawScan on May 10, 2026.
Overview
The Olvid channel is purpose-aligned, but it needs review because it can keep a reconnecting listener running, may cross account boundaries, and handles attachments with limited local safeguards.
Install only if you need an Olvid-to-OpenClaw chat channel and can use a dedicated, least-privileged Olvid bot key. Keep the daemon local or protected, limit trusted contacts/groups, and look for fixes around stop handling, account fail-closed behavior, and attachment storage/path controls before using it for sensitive conversations.
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.
The Olvid listener may continue receiving messages and producing agent replies after a user expects the channel/account to stop, until the OpenClaw process is restarted or otherwise killed.
The monitor accepts an abort signal but the reconnect loop shown here is controlled by a module-global flag and does not check the abort signal, creating unclear stop containment for a background channel.
abortSignal?: AbortSignal; ... globalRunBot = true; while (globalRunBot) { ... await bot.waitForCallbacksEnd(); ... await new Promise(resolve => setTimeout(resolve, 5_000)); }Honor the provided abort signal, maintain per-account run state, explicitly stop the Olvid client, and make the stopAccount hook terminate the monitor loop.
If reply media paths can be influenced by agent output or untrusted prompts, the plugin could attach local files that were not intentionally selected for sharing.
Outbound media paths are passed directly to the Olvid SDK as local attachment file paths without channel-side path allowlisting, source validation, or user approval shown in the artifacts.
await olvidClient.messageSendWithAttachmentsFiles({ discussionId, body: text, replyId: ..., filesPath: opts.mediaUrls });Restrict outbound attachment paths to an OpenClaw-managed media directory, require explicit user approval for arbitrary local paths, and reject absolute/protected paths by default.
Messages or attachments could be sent from the wrong Olvid bot identity, crossing the user’s intended account boundary.
A send requested for a specific Olvid account silently falls back to the default account credentials if the requested account is not fully configured.
if (!olvidAccount || !olvidAccount.daemonUrl || !olvidAccount.clientKey) { olvidAccount = resolveOlvidAccount({cfg: config as CoreConfig, accountId: "default"}); }Fail closed when a requested account is missing, disabled, or unconfigured; only use the default account when no account was requested and make the selected account visible.
Private Olvid attachments may remain on local disk or in session context longer than expected and could be reused or accessed outside the original conversation.
Incoming attachments are automatically saved to a predictable shared temp directory and the inbound context is recorded to session storage, with no cleanup, size limit, or retention policy shown.
fs.mkdirSync("/tmp/olvid-attachments", {recursive: true}); ... path: await attachment.save(this, "/tmp/olvid-attachments") ... recordInboundSession({ ... ctx: ctxPayload })Use per-session private temp directories, enforce size/type limits, delete attachments after processing unless the user opts in to retention, and document what message context is stored.
Anyone who can message the configured Olvid bot in an allowed discussion can influence what the agent is asked to do.
Olvid message text is intentionally converted into agent reply context and dispatched to the agent.
CommandBody: message.body, ... await runtime.channel.reply.dispatchReplyWithBufferedBlockDispatcher({ ctx: ctxPayload, cfg: this.cfg, ... })Connect the bot only to trusted Olvid contacts/groups, review routing rules, and keep high-impact agent tools behind approval controls.