XMemo for OpenClaw

What XMemo for OpenClaw does

XMemo for OpenClaw is a native OpenClaw memory provider identified by the xmemo-memory plugin ID. When selected as OpenClaw's active memory slot, it gives agents access to durable XMemo storage rather than exposing only an unrelated collection of auxiliary tools. The service can retain memories, return relevant context, and share user-visible information across approved clients.

The XMemo for OpenClaw MCP server includes core memory operations for semantic recall, exact lookup, saving, editing, listing, and deletion. It also covers durable TODOs, timeline milestones, restart or handoff snapshots, monthly ledger summaries, and authorized audit data. Ledger and audit access depends on the API-key scopes assigned to the connection.

This belongs in the 🧠 Knowledge & Memory category for applications that need continuity between sessions, shared context across agents, or explicit operational records alongside ordinary memory.

How it works

The plugin communicates directly with XMemo. Semantic search, persistence, and governance are handled by the XMemo service, so the OpenClaw host does not need to run a local embedding model or vector database. OpenClaw-authored memories are written to the configured bucket, which defaults to openclaw.

By default, recall can read all visible user-owned buckets. Operators can narrow reads with readBucket and readScope, while bucket and scope control where new memories are written. The default setup leaves automatic capture disabled. If enabled, capture is opt-in and subject to configured filtering and length limits.

XMemo for OpenClaw can use a user-scoped recall cache and write outbox to handle temporary network failures. The native plugin is separate from the XMemo Skill, which guides agent behavior, and from the hosted MCP endpoint at https://xmemo.dev/mcp, which provides a portable tool surface for MCP-compatible clients.

Setup and configuration

Install the plugin from ClawHub with openclaw plugins install clawhub:@xmemo/openclaw-memory, or install the npm package @xmemo/openclaw-memory. The normal setup command is openclaw xmemo setup --stdin; it enables the plugin, selects xmemo-memory as the active memory provider, and stores the credential source. Production deployments can reference an environment variable with openclaw xmemo setup --env XMEMO_KEY.

The minimum supported OpenClaw version is 2026.6.9. Configuration is stored under plugins.entries["xmemo-memory"].config. Supported settings include the XMemo baseUrl, API-key authentication, write and read buckets or scopes, an optional teamId, an attribution agentId, automatic-capture controls, and recall item and token limits. The hosted default is https://xmemo.dev.

Credentials may be supplied directly, through an environment SecretRef, through XMEMO_KEY, or from a shared credential created by xmemo login. Only environment SecretRefs are supported; file and exec SecretRef sources are rejected.

Tools and capabilities

• Search visible XMemo memory semantically with memory_search.
• Retrieve, save, update, list, or delete memories.
• Create, list, and complete durable TODOs.
• Record timeline events and save or restore restart snapshots.
• Read monthly ledger summaries and authorized audit events or consolidations.
• Share recall across connected agents that can access the same user-owned XMemo data.

The core memory_* tools are used by the OpenClaw agent during a turn and are not shell commands. For OpenClaw deployments, the native plugin is the primary memory operation surface; adding the hosted MCP endpoint creates a second XMemo tool surface.

Limitations and notes

The plugin is not bundled with the default OpenClaw release. It requires an XMemo credential and access to the configured XMemo service. Ledger and audit tools require matching API-key scopes. Automatic capture is disabled unless explicitly enabled.

Cross-agent recall is limited to memories visible to the authenticated user and any configured read restrictions. The plugin supports hosted or private XMemo services through baseUrl, but the provided material does not specify deployment instructions for a private service. The deprecated token configuration field remains accepted as an alias for apiKey, while new setup uses apiKey.