DEV Community: Shawn Sammartano

I Gave OpenClaw a Way to Bi-Directionally Communicate with other AI Tools and a Memory That All of them (10+) Can Read Simultaneously

Shawn Sammartano — Sat, 25 Apr 2026 00:55:21 +0000

This is a submission for the OpenClaw Challenge.

What I Built

I built a sovereign memory layer that sits underneath OpenClaw and every other AI tool on my machine — and made all of them share the same brain.
The problem: every AI app on my machine had its own memory silo. ChatGPT didn't know what I told Claude. Claude didn't know what I discussed in OpenClaw. OpenClaw didn't know what any of them knew. Each one was a brilliant amnesiac in its own little box.
So I built BubbleFish Nexus — an AGPL-3.0 Go binary that runs as a local daemon, and a TypeScript plugin (@bubblefish/openclaw-nexus) that drops OpenClaw straight into the same memory pool as nine other AI clients:

Claude Desktop (MCP over stdio)
Claude Code (MCP)
ChatGPT (OAuth 2.1 + PKCE over a Cloudflare tunnel) and WebUI
Perplexity Comet (SSE over the same tunnel)
Claude Web (?key= URL parameter)
OpenClaw (TypeScript ESM plugin in WSL2)
Open WebUI + Ollama (Pipelines)
Cursor (MCP)
Windsurf (MCP)
Cursor

One daemon. One memory store. Nine transports. Every byte signed by source identity. Every audit entry hash-chained. Survives kill -9 mid-write with zero data loss.

Then I went further. I forked OpenClaw locally and gave it a JSON-RPC receiver so Claude Desktop can hand OpenClaw a task through Nexus's governed bridge — full agent-to-agent dispatch with policy approval, capability grants, and audit correlation across both sides.

Repo: github.com/bubblefish-tech/nexus

How I Used OpenClaw

Part 1: The plugin — OpenClaw joins the memory pool
OpenClaw's plugin system is delightful. The definePluginEntry + api.registerTool() pattern with @sinclair/typebox schemas meant I could expose Nexus's capabilities to OpenClaw's agent in roughly 200 lines of TypeScript.

The plugin lives at ~/.openclaw/plugins/bubblefish-nexus/ and registers three tools the OpenClaw agent can call directly:

typescriptapi.registerTool({
name: "nexus_write",
description: "Save a memory to BubbleFish Nexus. " +
"Memories persist across sessions and are " +
"accessible from every other connected AI client.",
parameters: Type.Object({
content: Type.String(),
subject: Type.Optional(Type.String()),
tags: Type.Optional(Type.Array(Type.String())),
}),
required: true,
handler: async (input) => {
return await nexusClient.write(input);
},
});

api.registerTool({
name: "nexus_search",
description: "Retrieve relevant memories from Nexus. " +
"Includes memories written by Claude Desktop, " +
"ChatGPT, Cursor, and any other connected client.",
parameters: Type.Object({
q: Type.String(),
profile: Type.Optional(Type.Union([
Type.Literal("wake"), // sub-millisecond
Type.Literal("balanced"),
Type.Literal("deep"),
])),
}),
required: true,
handler: async (input) => {
return await nexusClient.search(input);
},
});

api.registerTool({
name: "nexus_status",
description: "Check Nexus daemon health.",
required: false, // user must opt in
handler: async () => await nexusClient.status(),
});
Configuration is three environment variables in openclaw.json:
json{
"env": {
"NEXUS_URL": "http://172.30.80.1:8080",
"NEXUS_DATA_KEY": "bfn_data_…",
"NEXUS_SOURCE": "openclaw"
}
}

The non-obvious part was the WSL2 networking. OpenClaw runs in WSL2; Nexus runs natively on Windows. WSL2 can't reach localhost:8080 on the host, so I:

Rebound Nexus's HTTP API from 127.0.0.1:8080 to 0.0.0.0:8080
Set up a netsh port proxy on the Windows side at port 18080
Pulled the WSL2 default-gateway IP from /etc/resolv.conf for the plugin's NEXUS_URL

After that, OpenClaw is a peer in the pool. Anything OpenClaw writes is searchable from every other client. Anything those clients wrote is searchable from OpenClaw.

Part 2: Bi-directional — Claude Desktop hands OpenClaw a task
Reading shared memory is half the trick. The other half is commanding across vendors.

I added a small JSON-RPC receiver to my local OpenClaw fork that speaks A2A v1.0, plus a Nexus-specific extension at the namespace sh.bubblefish.nexus.governance/v1. Now from Claude Desktop, I can do this:

"Ask OpenClaw to send a Signal message to my wife saying I'll be late for dinner."

Here's what actually happens:

Claude Desktop calls Nexus's MCP bridge tool a2a_send_to_agent with agent=openclaw, skill=send_signal_message, input={…}.

Nexus's policy engine evaluates the request against the grant table — does client_claude_desktop have capability signal.send on agent openclaw? It does (I granted it once via the consent UI).

Nexus dispatches a JSON-RPC tasks.send to OpenClaw's receiver over its HTTP transport. The envelope carries the governance extension with the Nexus instance ID, audit ID, and the policy decision.
OpenClaw validates the message, writes the task to its WAL-backed task store as state=working, and invokes the existing Signal channel skill — completely untouched OpenClaw code.

Signal sends. OpenClaw transitions the task to completed, writes an artifact with the message ID, and echoes a localAuditId back to Nexus.
Nexus chains both audit IDs into its hash-chained log and returns the result up to Claude Desktop.

End-to-end on a fresh dev machine: under three seconds, with full cryptographic correlation across two AI vendors and one channel provider. No human-in-the-middle for already-granted capabilities. A confirmation prompt for ungranted ones.

In the video examples I included below I ask Claude to tell Openclaw to create a file, you can see when it hit's the daemon. I hit F5 to refresh the folder and the file appeared. In the second video, I had 9 AI tools with a mixture of the desktop apps which routed through cloud to Nexus on my computer via secure tunnel, and local AI tools that connected in various ways to Nexus. Openclaw was able to retrieve ther message.

The transport layer supports four modes — stdio (subprocess), http (loopback), tunnel (Cloudflare-fronted for cross-machine), and wsl (the special case for OpenClaw-in-WSL2 dispatched from Windows-native Nexus). All four pass the same end-to-end integration test.

Part 3: The cryptography that ties it together
Every memory written through the plugin — by OpenClaw or any other client — carries:

Source signing: an Ed25519 signature with a per-source private key, so we can prove which client wrote what
Hash-chained audit: each write appends to a SHA-256 chain; tampering with any earlier entry invalidates everything after it
Daily Merkle root: at midnight UTC, all chains roll up to one root, which gets externally anchored
WAL-backed durability: the daemon survives kill -9 mid-write with zero data loss

Demo

2026.04.15_Claude_Code_To_OpenClaw_Through_Nexus.mp4
2026.04.10%20-%20BubbleFish-Nexus%20-%20All%20The%20Things_Video.mp4
VID_20260406_201031.mp4
VID_20260406_201026.mp4

What I Learned

OpenClaw's plugin model is the right shape. The decision to hand the agent a typed tool surface — instead of forcing every integration to be a chat-message hack — is what made the entire Nexus integration possible in 200 lines of TypeScript. Most "personal AI" platforms make you fight the framework before you can extend it. OpenClaw doesn't.

WSL2 networking will eat a day if you're not careful. Mirrored networking mode (Windows 11) and NAT mode have different gateway IPs and different reachability stories. The pattern that worked: Nexus binds 0.0.0.0, Windows runs a netsh port proxy, OpenClaw reads the host IP from /etc/resolv.conf at startup. Document it in your plugin SETUP.md or your users will fight the same fight.

Memory across vendors changes the texture of the assistant relationship. Once OpenClaw, Claude Desktop, and ChatGPT all read the same brain, the difference between them collapses to capability, not recall. ChatGPT is the one with browsing. OpenClaw is the one with skills and cron. Claude is the one with deep code reasoning. They stop being three separate products and start being three lobes of one assistant. That's the actual user experience, and it only shows up when you wire them all to one sovereign store.

Cross-vendor command needs governance built in from line one.
I almost shipped the A2A receiver without policy enforcement, "we'll add it later." Then I sketched what an unscoped grant would let an autonomous agent do across vendors and immediately backed up. Capability grants, two-step consent for ALL-scope, per-tool revocation, and audit correlation aren't optional features; they're the price of being allowed to do this at all.

The cryptographic story sells itself once people see one tampering demo. The first time a viewer sees sqlite3 mutate a memory and the verifier turn red, they understand the entire architecture in five seconds. Nothing else I could have shipped would land the "this is real infrastructure" point that fast.

I'll be pushing out Nexus v0.1.3 with a huge addition of features. Same day I'll make my Openclaw fork (BubbleClaw) available, which I optimized for bi-directional communication and also automatic handshake with Nexus on Github:

BubbleFish Technologies, Inc. · GitHub

AI Infrastructure. BubbleFish Technologies, Inc. has one repository available. Follow their code on GitHub.

github.com

ClawCon Michigan

I didn't make it to Ann Arbor on April 16 — I'm building from the high desert of northern Arizona, and Crisler Center was a longer drive than I could spare with a v0.1.3 ship line in front of me. I followed the live demos and announcements online and the energy of a community converging on personal AI sovereignty was unmistakable.

If ClawCon comes to the Southwest, or if there's a virtual track for the next event, I'd love to demo this side-by-side with whoever's running the most interesting OpenClaw stack in the room. The whole point of the integration is that OpenClaw doesn't have to be alone, it can be the agent layer for a much bigger personal AI ecosystem. That story belongs in front of the OpenClaw community, not just on Dev.to.

I built a crash-safe AI memory daemon that survives kill -9. Here's what it does.

Shawn Sammartano — Sat, 11 Apr 2026 00:46:04 +0000

I told Ollama "I just moved to Austin." Then I opened Claude Desktop and asked "where do I live?" Claude said Austin. I never told Claude anything.
Both apps were reading and writing to the same memory daemon on my machine. That's BubbleFish Nexus. This post is about what it does, why I built it, and what I learned shipping it solo over the past few months.

The problem

Every AI app keeps its own memory silo. ChatGPT doesn't know what you told Claude. Claude doesn't know what you told Ollama. OpenClaw doesn't know what any of them know. Switch tools and you re-explain everything.
There are hosted memory services that solve this, but they all want your data on their servers. I wanted something different: one daemon you run yourself that any AI client can connect to, with the same memory shared across all of them.

What Nexus is

A single Go binary. AI clients connect over HTTP, MCP, or OAuth 2.1. Every write goes through the same pipeline — auth, policy check, durable write, queue dispatch, destination commit. Every read goes through a multi-stage retrieval pipeline that combines metadata filtering, semantic search, and time-aware reranking so newer facts outrank older contradictions.
Seven AI clients are verified working today: Claude Desktop, ChatGPT (through a real OAuth 2.1 authorization code flow), Perplexity Comet, Ollama, Open WebUI, OpenClaw, and anything that speaks HTTP.

The crash safety story

This is the part I cared about most. If a memory daemon loses data on a crash, it's worthless. I wanted to be able to kill the process mid-write and have zero data loss.

I verified this by hand before I put the claim in the README. Wrote real memories, force-killed the process, restarted. Every memory came back with full content. There's a built-in bubblefish demo command that does this automatically with 50 memories — writes them, kills the daemon, restarts, queries, and asserts all 50 are present with zero duplicates. It's also the demo I use when people ask "but does it actually work?"
The architecture is documented at a high level in the README. I'm keeping the deeper internals out of public writeups for now, but the externally observable guarantee is simple: if Nexus returns 200 on a write, that memory is durable. If it returns 429 because the queue is full, the memory is still durable — the destination just hasn't caught up yet. There is no window where data is at risk.

What I learned shipping solo

The hardest part wasn't any single feature. It was the integration work. Connecting seven different AI clients meant seven different transport protocols, seven different auth models, seven different payload shapes. The real value of Nexus isn't any one of those integrations — it's that they all share one memory backend, so a fact written by one client is immediately visible to the others.

The second hardest part was getting the testing right. 607 tests across 31 packages, all green under the Go race detector, on Windows. CGO_ENABLED=1 for race testing, pure Go for normal builds. I shipped nothing until every test passed three times in a row.

Try it:

bashgit clone https://github.com/bubblefish-tech/nexus.git
cd nexus
go build -o bubblefish ./cmd/bubblefish/
./bubblefish install --mode simple
./bubblefish start

That's the setup. SQLite backend, single source, auto-generated API key, bound to localhost. The installer prints your key and an example curl command. Or grab a pre-built binary from GitHub Releases — no Go installation required.

Repo

AGPL-3.0. Solo dev. Built at my desk in Prescott, Arizona over the past few months with Claude Code as my pair programmer.

[(https://github.com/bubblefish-tech/nexus)]

Happy to answer questions about the architecture at the level the README covers, or about the integration work for any of the seven AI clients. If you've built anything in this space, I'd love to hear how you approached durability — it's the design constraint I spent the most time on.