You spend an hour briefing Claude Code on the project background, coding conventions, and deployment preferences. The next morning you open a fresh session and it stares back blankly, so you start over. The fix lives on two roads. One is self-built: our August 8, 2026 guide on setting up a long-term memory system for agents walked through a vector store plus flat files from scratch, for readers who refuse third-party dependencies. The other road is a ready-made product — and that is this article. MemHub is the local-first memory hub Tencent Hunyuan open-sourced on October 16, 2026, as part of the full three-layer Hy Memory release. The goal: install it today and have two of your AI tools share one memory.
One warning up front, in bold: MemHub does not support Windows. The README's platform section says exactly that, with no timeline. Many of this site's readers run Windows; for them the hands-on part is off the table for now, though the architecture overview, privacy boundaries, and FAQ still hold up, and you can return once support lands. Linux and macOS users can follow along and expect results within ten to twenty minutes.
What MemHub is: one local memory, many clients
The official positioning calls MemHub a "local-first shared memory product." It works in three steps. First, you authorize it to import conversation history and coding traces from tools you already use, such as Claude Code or Cursor. Second, it distills that material into structured memory on your machine, with everything landing under ~/.one-memory. Third, you separately grant each tool permission to read that memory. From then on, every new session in any connected client starts with the same context.
This differs from how memory layers were usually attached. Whether you used mem0 or a self-built stack, you called an SDK inside your own code and rerouted your data flow, paying the integration cost per project. MemHub works from the host side instead, reaching existing clients through skills, hooks, plugins, and MCP bridges — the official write-up calls it one-click integration. Old histories can be imported and distilled; new sessions sync in real time. Your habits stay the same; every client just gains a shared memory underneath.
Several core principles from the README deserve close quoting: one installation, one Runtime, one copy of data, many clients; the Python Core is the single memory data plane and the only writer to the business database; source reading, model processing, and host reading are independent authorization boundaries; the formal pipeline runs through Evidence, Hy Memory, Governance, and Matters/Wiki. In plain language: one copy of the data, every reader and every read an explicit grant, no path for a host tool to quietly vacuum up your full history.
Architecturally, apps/core is a Python/FastAPI kernel handling evidence, the memory engine, governance, and retrieval; apps/cli is the install-and-diagnose command line; apps/web is the management interface; apps/desktop is an Electron shell, macOS only; packages/host-bridge carries the per-tool integrations. Underneath sits the Hy Memory SDK — PyPI package hy-memory, currently 2.0.3. Keep the names straight: Hy Memory is the engine and SDK; MemHub is the product on top.
Memory here is not archived chat logs. Chat memory is reorganized into event threads — time, place, people, and what happened next — with duplicates merged and conflicts stripped before a model ever sees it. Working memory holds task goals, decisions made, intermediate results, and reusable lessons, each tagged with applicable conditions and checked for fit before reuse. Code memory forms version-evolution diff chains, storing real code differences. What gets stored is distilled structure, not raw logs, so recall wastes far fewer tokens — the fundamental difference between a memory layer and stuffing history files into context.
Installation: two tracks, pick yours first
Track one: SDK only, write your own code. Install the memory engine with pip:
pip install hy-memory==2.0.3The version is pinned at 2.0.3 so this article stays reproducible; check PyPI for the current latest. Configuration and the search return format live in the repository's MEMORY.md.
Track two: the full hub experience, MemHub itself. The entry point is the npm package memhub-cli, but that is only a Bootstrap installer of roughly 384KB — no Python Core, no SQLite storage, no web interface, no bundled Node, no models. The Runtime that does the real work is downloaded and verified only when you explicitly run memhub install. The README stresses that npm's postinstall does not download the Runtime, register services, or modify your shell profile. The installer stage is clean; npm uninstall removes it completely.
npm install -g memhub-cli
memhub installWhere things land matters. The Python Core and its dependencies live inside the MemHub-managed Runtime, never your system Python, so memhub upgrade leaves your existing environment untouched. SQLite data sits separately at ~/.one-memory, so upgrading the Runtime never touches your data.
Platform support is the most important fact in this section, bolded again: MemHub v1.0.3 supports Linux and macOS only, and Windows is not supported. Linux ships Runtimes for x64 and arm64, built on native-architecture runners and acceptance-checked; macOS ships Apps and Runtimes for arm64 and x64, Developer ID signed and notarized. To repeat for the readers this matters most to: Windows users cannot install this release, and the README has no "planned support" wording. The project moves fast — commits referencing 1.0.4 are already visible — so treat the GitHub Release page as the source of truth before you start.
The ten CLI commands, one by one
MemHub's entire lifecycle runs through a single memhub command. The README lists ten:
memhub serve
memhub start
memhub stop
memhub restart
memhub status
memhub doctor
memhub install
memhub upgrade
memhub uninstall
memhub delete-dataWalking through them. memhub install downloads and verifies the Runtime matching your version — step two of installation. memhub serve starts the full Runtime in the foreground, what you want on the first run to watch logs. memhub start hands the Runtime to a system service for background hosting; that is the everyday mode. memhub status shows the running state. memhub restart and memhub stop manage restarts and shutdowns. memhub doctor runs an environment self-check — run it right after installing, and first whenever something misbehaves. memhub upgrade upgrades the Runtime. memhub uninstall removes the service, managed Runtime, and CLI links, keeping memory data by default. memhub delete-data is the only command that deletes data, requiring a stopped Runtime and a second confirmation of the exact path.
A typical first run:
npm install -g memhub-cli # Bootstrap installer, about 384KB
memhub install # Download and verify the full Runtime
memhub doctor # Environment self-check
memhub serve # First run in the foreground
# Once clean, daemonize
memhub start
memhub statusThree details. First, one-memory is kept as a legacy-compatible command, equivalent to memhub. Second, npm uninstall memhub-cli removes only the installer; full removal means memhub uninstall, then memhub delete-data only if you truly want the data gone. Third, on macOS the App and the CLI share a single LaunchAgent, so deleting the App stops only the App-owned service while the CLI-owned one keeps running.
Which AI tools: two counts, side by side
This is the one place where sources disagree, and both counts are reported rather than one being picked. The README explicitly names five tools: Claude Code, Cursor, Codex, OpenCode, and Qwen Code. Tencent Hunyuan's official WeChat article claims support for ten, adding WorkBuddy, Pi, Hermes, DeepSeek Harness, and others.
Use your own machine's memhub output as the decisive list. The README leans conservative and the WeChat article leans complete; both can be true at different times. The only judgment that matters is whether your daily driver appears. If it is one of the five named tools, install with confidence; otherwise, install first, then run memhub doctor and check the management interface before building on top.
A concrete scenario: you settle a convention with Claude Code in the morning — this repo uses pnpm, commits follow Conventional Commits. In the afternoon you switch to Cursor, open a new session, and those conventions are already in context. No re-briefing, no preferences file pasted around. Writing and recall both happen on the MemHub side; the host tool just pulls what it needs, and the only thing you notice is that it remembers.
Privacy: five "no's" as the trust baseline
The biggest worry with any product that ingests your work is what exactly it collects. MemHub's README states the boundary item by item: no screen capture, no OCR, no keyboard or mouse event collection, no clipboard reading, no audio recording. The Accessibility/AXTree channel is explicitly excluded too.
The weight of these five items shows by comparison. Plenty of "memory" or "productivity" tools run on screenshot-plus-OCR pipelines or log keystrokes to infer what you are doing. MemHub's data plane consumes only the histories and coding traces you explicitly authorize, and with source reading, model processing, and host reading fenced off as independent boundaries, there is no room to quietly grab more. The repository ships PRIVACY.md and SECURITY.md; read them if you want the fine print. For a product whose job is collecting your work conversations, these five no's are not a bonus — they are the admission ticket.
One pacing suggestion: imports happen per tool and per source. Authorize only your most important client first, run it a week or two, check the distilled memory quality, then import the rest. If you get it wrong, memhub delete-data resets the slate — but rebuilding a week of working memory is real effort, so start slow.
Preview warning and three pitfalls
MemHub is in preview. Bolded in the README itself: the public release can be downloaded and evaluated, but some platform artifacts, installation paths, and host integrations are still being completed and verified. APIs and commands can change; production use is discouraged. Turn "check the release notes" into a habit: before every upgrade, glance at the GitHub Release artifact list — only artifacts in both the Release and the release manifest, passing public verification, count as formally supported.
Three pitfalls. First, do not treat ~/.one-memory as an ordinary cache — it is the entire memory store, and deleting it is unrecoverable; the sanctioned path is memhub delete-data with its double confirmation. Second, when filing an issue, attach the MemHub version, OS and architecture, reproduction steps, expected versus actual results, and sanitized logs — and no API keys, real conversations, or personal paths. Third, run memhub doctor right after installation; most install failures — incomplete downloads, architecture mismatches, unregistered services — get reported there directly.
How this splits with the self-built route
Our August 8, 2026 guide covers the self-built road: a vector store plus flat files from scratch, zero third-party dependence, a data chain you fully own — right for teams with engineering capacity and deep customization needs. MemHub sits at the other end: a ready-made open-source solution where installation gets you a Runtime, a management interface, and multi-tool integration, at the cost of accepting its authorization model and preview status. The one-line division of labor: total control and tolerance for work, read the self-build guide; running today with local managed hosting, use this one. The roads are not exclusive — validating the need with MemHub first, then committing to a self-built stack, is a sensible sequence.
FAQ
Q1: What about Windows users? A1: MemHub v1.0.3 does not support Windows — the README states it outright, with no timeline, and mentions no WSL-style workaround. Do not force unverified detours. Windows users can bridge the gap with the self-built memory approach, which has no platform restrictions, and return once official support arrives.
Q2: Where is the data stored? Does it go to the cloud?
A2: All memory data lives locally under ~/.one-memory; the positioning is explicitly local-first, and the data plane is local SQLite-style storage only. Cloud sync is not mentioned anywhere in the README, so treat it as nonexistent. The only deletion path is memhub delete-data, requiring a stopped Runtime and a second confirmation.
Q3: How many AI tools does it actually support?
A3: Both counts, side by side: the README names five — Claude Code, Cursor, Codex, OpenCode, Qwen Code — while the official WeChat article claims ten, adding WorkBuddy, Pi, Hermes, DeepSeek Harness, and others. The sources disagree; this article picks neither. Defer to the integration list your local memhub shows.
Q4: Does it secretly capture my screen, keyboard, or microphone? A4: Per the README's boundaries, all five are off the table: no screen capture, no OCR, no keyboard or mouse events, no clipboard reading, no audio recording — Accessibility excluded too. The data plane only consumes histories and coding traces you explicitly authorize for import.
Q5: Can I run it in production? A5: Not recommended. MemHub is in preview; some platform artifacts, installation paths, and host integrations are still being verified, and APIs can change. Personal machines and team evaluations are fine; for production pipelines, wait for it to graduate — or evaluate the self-built route instead.
Related reading
- AI Agent Long-Term Memory Setup SOP: Making Agents Remember You Across Sessions: AI Agent Long-Term Memory Setup SOP
- AI Memory Framework, Open-Sourced: Tencent's 3B Tops Opus 5: AI Memory Framework, Open-Sourced: Tencent's 3B Tops Opus 5
- codebase-memory-mcp Code Intelligence Engine: codebase-memory-mcp: a code intelligence engine for agents