remindb-local-hub

ReminDB-Local-Hub

Agentic memory in a single SQLite file.
Stop letting your agent re-read the same notes every session.

---

ReminDB-Local-Hub

ReminDB-Local-Hub makes the remindb binary work correctly on Windows and multi-agent workstations. Pre-built releases are published from v0.1.0 onwards for linux / darwin / windows × amd64 / arm64.

The original remindb serve command is stdio-first: each MCP client normally starts its own server process. That is fine for one terminal, but it is the wrong topology when Claude Code, Codex, Gemini, and other agents all point at the same SQLite database. ReminDB-Local-Hub runs exactly one DB-owning server and lets every MCP client connect through a tiny stdio bridge.

What ReminDB-Local-Hub adds:

• remindb serve --listen 127.0.0.1:39291 for a singleton local MCP server.
• remindb bridge so existing stdio MCP clients can connect to that singleton server.
• FTS5 query hardening for real vault terms such as three-tier, LR-2026-..., NEAR(three-tier stack), and three-tier*.
• Windows path-prefix compatibility so the test suite and path hashing behave correctly on Windows.
• install.ps1 and install.sh installers on the main branch root, plus tag-triggered GoReleaser builds; remindb update reinstalls in place.

flowchart LR
    subgraph Clients["MCP clients"]
        direction TB
        Claude["Claude Code"]
        Codex["Codex"]
        Gemini["Gemini CLI"]
        OpenCode["OpenCode"]
        OpenClaw["OpenClaw / others"]
    end

    subgraph Bridges["one stdio bridge per client"]
        direction TB
        ClaudeBridge["remindb bridge"]
        CodexBridge["remindb bridge"]
        GeminiBridge["remindb bridge"]
        OpenCodeBridge["remindb bridge"]
        OpenClawBridge["remindb bridge"]
    end

    subgraph Hub["ReminDB-Local-Hub"]
        direction TB
        Listener["127.0.0.1:39291"]
        Server["single remindb serve --listen"]
        Tools["Memory* MCP tools"]
        Lock["Store.OpMu write lock"]
        DB[("SQLite memory DB")]
    end

    subgraph Corpus["indexed corpus"]
        direction TB
        Source["vault / docs / agent memory"]
        Rescan["compile + background rescan"]
    end

    Claude -->|stdio| ClaudeBridge
    Codex -->|stdio| CodexBridge
    Gemini -->|stdio| GeminiBridge
    OpenCode -->|stdio| OpenCodeBridge
    OpenClaw -->|stdio| OpenClawBridge

    ClaudeBridge -->|localhost TCP| Listener
    CodexBridge -->|localhost TCP| Listener
    GeminiBridge -->|localhost TCP| Listener
    OpenCodeBridge -->|localhost TCP| Listener
    OpenClawBridge -->|localhost TCP| Listener

    Listener --> Server
    Server --> Tools
    Tools --> Lock
    Lock --> DB

    Source --> Rescan
    Rescan --> Server

Topology choice

The v0.1.0 binary supports two shapes. Both are valid; the right one depends on how many clients share the database.

Shape	Process model	When to use
Per-client serve (simpler)	The MCP client spawns its own remindb serve on stdio and opens the .db directly. SQLite WAL handles multi-process safety, but every additional client duplicates the rescan loop and fragments temperature counters across processes.	1 client. The simplest possible wiring.
Singleton serve --listen + per-client bridge (marquee, supports 2-20 clients)	One remindb serve --listen 127.0.0.1:39291 owns the DB. Each client spawns remindb bridge, which forwards stdio MCP frames over loopback TCP. Diagram above.	2 or more concurrent clients sharing one DB, up to ~20. One process owns rescan, write serialization, and the cold-node notifier; temperature counters stay coherent.

Per-client serve is the single-client shape — one MCP client speaks stdio to one remindb serve, which owns the .db. No diagram needed; it is just client -> remindb serve -> .db.

Migration between the two shapes is reversible — swap serve for bridge --addr ... in each client's MCP config. The MCP tool surface is identical either way.

Security boundary: ReminDB-Local-Hub is for localhost. MCP has no auth here; do not bind --listen to a public interface.

Why This Exists

Coding agents already have memory. CLAUDE.md, AGENTS.md, your notes folder, that growing pile of project READMEs. Stuff persists just fine.

The problem is how the agent consumes it. Every session starts by re-reading the whole pile from scratch — every Read, every Grep, scanning raw prose the agent has already processed dozens of times. Big context windows don't fix it. A 1M-token window is still paid per call, and still can't tell yesterday's stale note from today's relevant one.

Raw markdown is the wrong shape for memory. Not because it can't hold the words — it can — but because it forces the agent to pay full freight on every read.