dreamd
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@dreamdsearch memory for axum error handling lessons"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
dreamd
The plain files in your repo are the memory. dreamd is the local server that reads and writes them.
Drop a .agent/ folder in the project. Claude Code, Cursor, Cline, and other MCP-aware harnesses share it. What one agent learns, the next already knows. You can cat, grep, and git diff every byte. Durable appends go through MCP / the daemon so the writer stays single-writer.
This is not "another memory product." It is a storage-model wedge: the filesystem is the source of truth, and the MCP tools (search_nodes / append_node) are a thin interface over those files.
Where dreamd fits. dreamd is one of three sibling repositories that make one product: dreamOS, the first computer you can hand your keys to — it acts on your behalf, it is structurally incapable of doing what you did not allow, and it can prove what it did. The kernel under it is momo; the sandbox beside it is aegis. momo's charter (its RFC-009, amended by RFC-011, accepted 2026-09-26) records dreamd as the Linux-hosted proof of one of the product's pillars: memory as plain files a person owns, with provenance — in the product's words, the Memory. The same amendment names the rule the provenance ledger grows toward — every effect can be traced to the data that caused it, and no datum can cause an effect above its own trust label — as a design with its own spec first. Nothing shipped implements a trust label: source_harness is asserted by the caller, the provenance ledger (docs/provenance.md) records derivation, not trust — it is unsigned and nothing gates on it — and SECURITY.md says plainly that injected lessons are not filtered. The momo repository is private until the kernel's first public release, and the product is not announced, previewed or marketed before its v1; this paragraph is a pointer, not a launch.
Open core: Apache-2.0 core today, self-hosted only. Premium features may ship later. Do not read this as free-forever for everything.
npx -y dreamd-mcp setup # scaffold .agent/ and wire your harness
npx -y dreamd-mcp # MCP server (stdio) — what the harness spawnsFirst run prints a local-only privacy disclosure.
setupprompts for harness choice when it has a TTY.
The moment it earns its name
~/project $ npx -y dreamd-mcp setup
# Claude Code, Tuesday:
you > axum keeps blowing up when I unwrap in route handlers
claude> filed under rust::error_handling::axum_rejection
# Cursor, Friday, fresh session:
you > why is this build failing?
cursor> You're unwrapping in a route handler. dreamd has a
lesson from Tuesday: axum needs IntoResponse on
custom Error types. Try `?` and a typed error.No re-explaining. No re-pasting. Same .agent/ folder, every harness.
Related MCP server: LongtermMemory-MCP
Install
npm (recommended)
npx -y dreamd-mcp setup # scaffold .agent/ + write the harness MCP config
npx -y dreamd-mcp # MCP server (stdio) — your harness spawns thisstdio stays the default transport. dreamd mcp --bind 127.0.0.1:<port> is the opt-in Streamable HTTP server at /mcp. It is unauthenticated, and it is only in source builds with --features mcp-http — see docs/mcp-transports.md.
Requires a project root sentinel (.git/, Cargo.toml, package.json, or pyproject.toml).
setup prompts when it has a TTY. In scripts and non-interactive shells, pass --yes --harness claude|cursor|both (--harness none or --no-write-mcp scaffolds without touching any MCP config).
Cargo / from source
git clone https://github.com/botzrDev/dreamd.git
cd dreamd
cargo install --path crates/dreamd-cliSee CONTRIBUTING.md for the full dev setup.
Quick start (< 30 seconds)
If ~/your-project is a brand-new folder, run git init first (or make sure it contains one of the supported root sentinels).
cd ~/your-project
npx -y dreamd-mcp setup
# Optional: shared daemon (recommended when several agents write)
npx -y dreamd-mcp watchReload your harness. setup already wired the dreamd MCP server, so the harness spawns npx -y dreamd-mcp itself — no config to copy by hand.
Ask the agent to search memory for something you just learned. It calls search_nodes and recalls prior context.
cat .agent/episodic/AGENT_LEARNINGS.jsonl
npx -y dreamd-mcp doctorThe npm shim does not put dreamd on PATH. Use npx -y dreamd-mcp <cmd> on the npm path, or cargo install --path crates/dreamd-cli if you want the dreamd binary. The shim forwards only some subcommands (npx -y dreamd-mcp --help lists them); recall, score, status, archive, and migrate need the dreamd binary.
Adapters: Claude Code · Cursor
What dreamd writes
Location | Contents | Commit? |
| Episodic JSONL, semantic lessons, personal prefs | Yes (this is the shared memory) |
| Local index, daemon state, config template, memory branches, provenance ledger | No (gitignored by |
| Which projects have a store | No |
| Daemon API socket (while running) | No |
npx -y dreamd-mcp setup (or dreamd setup after a cargo install) scaffolds the store by calling init, then writes the harness MCP config. init is the scaffold primitive and still works on its own when you want the store without touching any MCP config. Both are idempotent. To uninstall from a machine — stop local servers, remove the socket, unregister the current project, clear caches — run npx -y dreamd-mcp uninstall (project .agent/ stores are left in place). Advanced, registry-only: npx -y dreamd-mcp init --uninstall-project unregisters the current project and touches nothing else.
Inspecting and editing memory
The MCP surface is two tools. Everything else is CLI, run against the same files. These need the dreamd binary unless noted; dreamd <cmd> --help is the reference for flags.
Command | What it does |
| Ranked search as a markdown table. |
| Which stored memories drove a query's ranking: id, timestamp, |
| Top memories by salience alone, no query. |
| Salience distribution, top clusters, and drift against the snapshot from exactly seven days earlier. New in 1.0.0; forwarded by the npm shim. See docs/observability.md. |
| Print the |
| Name snapshots of the memory files, switch between them, diff two, and binary-search the automatic |
| Remove one episodic event and the lesson state that names it. |
| Recompute the provenance ledger's Merkle root and list orphan edges, missing edges, and corrupt lines. Read-only. New in 1.0.0. See docs/provenance.md. |
Architecture (one paragraph)
Agents talk to dreamd over MCP (search_nodes, append_node). On Linux and macOS the MCP server proxies to a single-writer daemon (dreamd watch) over HTTP on a Unix domain socket, or runs in-process when no daemon is present. On Windows it proxies to loopback dreamd watch and exits 2 when that daemon is down; there is no in-process server. The coordinator appends to AGENT_LEARNINGS.jsonl and feeds a Tantivy BM25 index. Recall ranks hits with a query-time salience formula (BM25 × age decay × pain × importance × recurrence). Each hit carries source_harness and skill_action, so recall is attributable across harnesses. The dream cycle consolidates episodic learnings into LESSONS.md under WAL protection.
Recall is deliberately lexical (BM25 + salience), including the LESSONS.md document layer indexed alongside episodic events. That is a scope choice, not a scoreboard claim. Vector / embedding recall is not shipped: the optional vectors cargo feature (off by default, not in release binaries) only downloads a model, and nothing ranks with it (docs/vectors.md).
Details: ARCHITECTURE.md · SPEC.md · docs/http-api.md
FAQ
Is this the first / only cross-harness memory? No. Other projects exist (including large ones). dreamd owns the storage-model wedge: plain files you already version-control, not a category claim.
Do I need Rust? No for the recommended path. npx -y dreamd-mcp downloads a prebuilt binary. Rust is only required if you build from source.
Where does memory live? In <project>/.agent/. The daemon and index under .agent/.dreamd/ are local and gitignored. You can read and edit the JSONL / Markdown by hand; durable appends should go through the daemon / MCP so the writer stays single-writer.
What if I want a full wipe? See Full fresh store. There is no dreamd reset --all. To uninstall dreamd itself, run dreamd uninstall — details: packages/dreamd-mcp/README.md. That stops running processes and clears caches; removing the per-user service entry (the systemd unit, the LaunchAgent, or the Windows Task Scheduler logon task) is the separate dreamd service uninstall, whose optional --purge deletes the daemon home ~/.agent/ and never a per-project .agent/ store (docs/install.md).
Windows? Partial. dreamd watch serves the HTTP API on loopback TCP with a bearer token from auth.json; POST /api/v1/learn works. The dream cycle and Tantivy index do not — io::write_atomic is still Unsupported there. For consolidate-and-search, use WSL2 or a Linux/macOS host. The npm shim downloads prebuilt binaries for Linux x86_64 and macOS (x86_64 / arm64) only, so native Windows means a cargo build. Details: docs/windows.md.
Is everything free forever? Apache-2.0 core is open. Premium may come later. Self-hosted only (no hosted SaaS).
More troubleshooting: docs/troubleshooting.md.
Roadmap
When | What |
v0.1.0 (2026-08-05) | BM25 lexical recall, Linux + macOS, deterministic dream cycle, npm |
v0.1.1 (2026-09-14) | LLM dream cycle, |
v1.0.0 (2026-10-02) | Stable release of the tree since v0.1.1: |
Next | Windows atomic writes (dream cycle + index), vector recall, WasTrue benchmark publish |
Documentation
Doc | What |
20-minute tutorial walkthrough | |
Full documentation index | |
REST API (Unix socket / Windows loopback TCP) | |
TOML config and env vars | |
Common failures | |
Domain terms | |
On-disk contract | |
Salience formula deep-dive | |
Memory branches: branch, checkout, diff, bisect | |
Provenance ledger format and what | |
Recall citations ( | |
Two-page | |
Engineering decisions | |
Dev setup and RFC process | |
Threat model | |
Product story and positioning |
Warm recall latency numbers (local Criterion benches) live in PERF.md if you want them. They are not the product pitch. To re-run the bench yourself, see docs/benchmarks.md.
Status
v1.0.0 is released (GitHub tag v1.0.0, 2026-10-02; npm dreamd-mcp 1.0.0 on latest and next). The tag adds no behavior of its own (CHANGELOG.md). The MCP Registry entry io.github.botzrDev/dreamd is a separate human publish (RELEASING.md). Commands marked "new in 1.0.0" above need 1.0.0 or later. CLI commands: setup, init, watch, mcp, dream, doctor, status, service, recall, blame, score, salience-drift, memory, forget, archive, migrate, reset workspace, vectors, uninstall, update, version (dreamd --help is the full list; on the npm path use npx -y dreamd-mcp <cmd> — the shim forwards a subset, see packages/dreamd-mcp/README.md). vectors enable exits 2 on the default build and does not change recall. Linux, macOS, and partial Windows (watch + learn; no dream cycle or index). If you upgrade a cargo-installed binary in place (cargo install --path crates/dreamd-cli) and run the daemon under the per-user service, bounce it afterwards with dreamd service restart so the supervisor picks up the new binary (docs/install.md).
Layer | Status |
| Shipped |
Reference implementation (daemon, HTTP API, dream cycle, Tantivy recall) | Shipped |
MCP server ( | Shipped on npm |
CI / cross-platform matrix | Lint, test, build, binary-size gate, DCO (Windows jobs are informational) |
Conformance | Reference-impl alpha suites ( |
WasTrue benchmark
A separate eval of whether memory systems update a fact that later changes. The harness in this repository is a scaffold, and a results table is not published here. Publishing that table is listed under Next above. Methodology for the scaffold: scripts/benchmark/README.md.
Platforms
Linux and macOS (full). Windows is watch + learn over loopback TCP; the dream cycle and Tantivy index stay Unix-only until atomic writes land. See docs/windows.md.
Contributing
See CONTRIBUTING.md. By participating you agree to the Code of Conduct. Security reports: SECURITY.md (do not open a public issue for vulnerabilities).
License
This server cannot be deployed
Maintenance
Related MCP Connectors
Cloud-hosted MCP server for durable AI memory
An MCP memory server. One memory your agents share — across models, devices and apps.
An MCP server that gives your AI access to the source code and docs of all public github repos
One memory, every AI. A shared, user-owned markdown memory your AI clients read and write over MCP.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceA local MCP server that gives AI coding agents persistent memory and context across sessions.11 npmMIT
- AlicenseAqualityAmaintenanceA fully local MCP server that gives AI agents persistent, semantic long-term memory without any cloud dependencies.1116 npm1MIT
- AlicenseAqualityCmaintenanceA local-first MCP server that provides a shared Markdown-based memory for AI coding agents, enabling cross-agent context persistence via tools like memory_search and memory_capture.101MIT
- AlicenseNot gradedqualityBmaintenanceAn MCP server that gives AI agents persistent, file-based memory stored as plain markdown files in a local git repository, enabling agents to remember, recall, and build on information across sessions.6 npm1MIT