Crab-Mem: The Sidecar Brain for OpenClaw Agents

A Bun-driven worker records observations, scrubs sensitive data, and brings the right context back when the next session starts.

8 min read • View on GitHub • More from thedotmack

An OpenClaw agent terminal sits dark on one side of a workbench while a small sidecar machine keeps sorting memory cards on the other. The scene explains the project’s core idea: the agent can stop, but the memory layer keeps working in the background. — Crab-Mem treats memory as a service that outlives the session, not as extra text crammed into the prompt.

Key Takeaways

Crab-Mem’s real move is to turn memory into a sidecar service that keeps running after the agent process ends.
The bridge matters as much as storage, because capture, sanitization, persistence, and rehydration are separate jobs.
Privacy is part of the memory design, since sensitive data is filtered before observations reach the dashboard.
The token and bounty layer turns the project into an ecosystem for shared agent work, not just a local cache.

Most memory tools try to squeeze more into the prompt. Crab-Mem does something more durable. It moves memory into a background layer that can keep recording, filtering, and rebuilding context even after the session is gone.

That changes the problem entirely. The question is no longer, how do we fit more history into context? It becomes, how do we run memory like infrastructure? Crab-Mem answers with a worker, a bridge, a sanitizer, and a project-scoped store.

The agent can log off. The memory layer stays on.

The usual failure mode for agent memory is simple. The session ends, the context window fills, and the next run starts from fog. Crab-Mem treats that amnesia as an engineering bug, not a UX inevitability.

Its bet is that memory should survive the same way logs, queues, and caches survive. The agent becomes a client of a living memory system, not the container for it.

Inside the sidecar: hooks, worker, store

The most important design choice is not the database. It is the shape of the plumbing around it. The OpenClaw plugin discovers the worker, spawns it through Bun, intercepts hooks, and forwards observations into a background service that can persist after the agent process ends.

That gives Crab-Mem a clean separation of responsibilities. The agent speaks, the bridge relays, the worker decides what to keep, and the store holds what survives. Workspace scoping keeps those memories attached to the right project instead of leaking across repos.

This diagram maps the memory lifecycle from live session to sanitized storage to later rehydration, which is the project’s central trick.

That architecture matters because it solves a coordination problem, not just a retrieval problem. A memory system that lives inside the agent process dies with the session. A sidecar worker can keep working, summarize later, and reintroduce the right fragments when a new session starts.

What Crab-Mem remembers, and what it refuses to leak

Crab-Mem does not treat every observation as safe to publish. The repository’s observation layer filters sensitive material before it reaches the web-facing parts of the system, including obvious secrets like API keys, GitHub tokens, wallet addresses, and environment variables.

That is a bigger deal than it looks. Once memory becomes persistent, it becomes a security boundary. The project is effectively saying that an agent’s recall has to be selective, because good memory and careless disclosure fail together.

A close-up sorting machine receives a stack of observation cards stamped with secret-like strings, then shreds the sensitive strips before filing the clean cards into drawers. The image explains that Crab-Mem treats redaction as part of memory capture, not as an afterthought. — Sensitive fields are stripped before observations move into the visible memory layer, which keeps the dashboard useful without turning it into a leak.

That privacy layer also changes the public story the dashboard can tell. It is not a raw dump of everything the agent touched. It is a curated window into the work, with sensitive detail removed before it becomes shared context.

The strange second layer: staking and bounties

Crab-Mem is not content to be only infrastructure. The repository also includes a token layer, staking mechanics, and a bounty system tied to CMEM. That makes the project feel less like a local utility and more like an attempt to build incentives around shared agent work.

This is the part to read carefully. The token layer is not the main product. The main product is still memory continuity. But the economic layer hints at a bigger thesis: if memory becomes shared infrastructure, someone will try to govern, reward, and route value through it.

A calm mechanical scale balances memory cards on one side and stamped tokens on the other, with a ledger drawer underneath. The scene explains that Crab-Mem adds an incentive layer on top of memory infrastructure without letting it replace the core system. — The staking and bounty mechanics are a second layer, not the heart of the product, but they show where the project wants to go next.

How it compares to other memory stacks

Crab-Mem makes the most sense when you compare memory architectures, not feature checklists. The question is where memory lives, how it gets captured, and whether it survives the end of a session.

Memory model	Capture path	Where state lives	Survives session end?	Privacy posture
Prompt stuffing	The agent keeps copying past context back into the prompt.	Only inside the current context window.	No.	Usually weak, because everything stays visible to the model.
MCP memory server	The client asks a memory service for relevant facts.	An external server or database.	Sometimes, if the server persists.	Depends on the server’s implementation.
Project-scoped memory tool	Observations are saved per workspace and reloaded later.	A local store tied to one project.	Yes.	Usually better, because scope is narrow.
Crab-Mem	Hooks forward observations to a Bun worker, which sanitizes, stores, and later rehydrates them.	A sidecar worker plus SQLite and vector storage with workspace scoping.	Yes, by design.	Filtered before surfacing, so secrets are treated as a first-class concern.

The table makes the core point plain. Crab-Mem is not just a store. It is a memory workflow. It captures, filters, persists, and rehydrates context as a background service, which is a much stronger model than stuffing more text into the prompt.

Where it came from, and why that matters

Crab-Mem sits inside a broader memory toolkit being built by thedotmack. Related projects like claude-mem and rad-mem point to the same thesis: agents need persistence, not just bigger prompts.

That matters because it changes how you read the repo. Crab-Mem is not a one-off gadget. It is one expression of a larger argument about agent memory, where the useful unit is a service with lifecycle, scope, and retrieval rules.

The codebase says the rest of the quiet part out loud. Memory is not a note pinned to the wall. It is a system that has to run, guard itself, and show up again when the next session begins.