MulmoClaude: a local-first AI assistant you build from plain files

The problem MulmoClaude picks, and who it is aimed at

The README opens with a claim rather than a feature list: an assistant that knows everything about you and runs around the clock "is not sold anywhere. You cannot buy one, you can only nurture one." That framing sets the scope. MulmoClaude is not a chat wrapper you point at an API key. It is an environment for accumulating context about one person, on one computer, over time.

The argument for local-first is stated as a lock-in argument, not a privacy slogan. The README says the substance of an assistant is not the model but how much it knows about you, and that something that important "should not be entrusted to any single service provider, the longer you use it, the harder it becomes to leave." Whether or not you accept the premise, it explains the design: memories, data and apps are plain files in a workspace, so the accumulated value stays portable.

The intended user is someone with a machine that can stay on, a Claude Code subscription, and a preference for inspecting their own data over convenience. The README is explicit that the garden is empty at install: "Right after install the garden is empty; you plant seeds and tend the soil." There is no onboarding dataset and no import path described for an existing assistant, so the first weeks are manual work.

How the plugin registry and schema-driven collections fit together

The architecture is described as an AI-native application platform. Capabilities live as plugins in a single registry. The README names the current set: a full accounting system with what it calls real server-side bookkeeping logic, a personal wiki, an SEC-filings reader, and more. Claude acts as a universal controller that composes across them, and chat is expected to summon the right GUI for the task: markdown, charts, forms, wikis, spreadsheets, or 3D scenes.

The mechanism that ties this together is schema-driven collections. The README describes "a place to keep your data (schema-driven collections, feeds, plain files)", which is how a request phrased in ordinary words becomes a structured store rather than a loose pile of notes. The repository layout backs this up: packages/ is split into workspaces for plugins, bridges and services, and package.json defines a codegen step, `plugins:codegen`, that regenerates plugin barrels and runs before both `dev` and `build`. Adding or removing a plugin therefore changes generated code, not just runtime configuration.

The remote story is narrower than it first sounds. The README says you can log in from your phone or a messaging app you already use and reach the same assistant, but that "the relay server only carries messages in transit, your memories, data, and apps never leave your computer." The relay is a message path. The workspace does not move.

Installing MulmoClaude and getting to a first chat

The README gives a single-command install. The launcher boots the server and opens the browser for you:

npx mulmoclaude@latest

After that command finishes starting, the README says the launcher opens http://localhost:3001 and you can start chatting. If the page does not load, the prerequisites are the first thing to check: Node.js 22.19 or newer, and the Claude Code CLI installed and authenticated. The README instructs you to run `claude` once to complete OAuth. ffmpeg is needed only for movie generation, and Docker Desktop is optional but recommended because it enables sandbox mode.

The README warns about one operational detail that catches people out: closing the terminal stops the server. To keep it running you launch inside tmux or screen on macOS and Linux, or as a startup task on Windows.

To launch without a terminal at all, the README offers a shortcut command that writes an app bundle:

npx mulmoclaude@latest create-shortcut

On macOS this writes MulmoClaude.app to /Applications, or to ~/Applications if that is not writable; `--dir <path>` chooses another location and `--yes` skips the prompt. On Windows the same command writes a Start Menu shortcut instead, with launcher files under %LOCALAPPDATA%\MulmoClaude. Two behaviours are worth knowing before you rely on the icon. First, the README says to re-run the command after upgrading, because the shortcut carries its own copy of the launcher. Second, an icon launch reads `~/.env` from your home directory, while a terminal launch reads `.env` from the directory you launched in, because macOS starts apps in `/` and Windows starts them wherever the shortcut points.

If you want to modify the code rather than just run it, the README's source path is a clone plus a dev server:

git clone git@github.com:receptron/mulmoclaude.git
cd mulmoclaude && yarn install
cp .env.example .env   # optional, add GEMINI_API_KEY for image generation
yarn dev

The dev server serves http://localhost:5173 rather than 3001. The README points at docs/developer.md for architecture and scripts, and at docs/troubleshooting.md for symptoms like icons rendering as words or a 401 after a restart.

Where the local-first promise has edges

The strongest claim in the README is that memories, data and apps never leave your computer. Read carefully, that sentence is scoped to the relay server. The assistant itself is driven by the Claude Code CLI, which is a network service, and the README lists an optional GEMINI_API_KEY for image generation. So the correct statement is that your stored workspace stays local; the reasoning over it does not. Anyone adopting this for data that must never reach a third party should treat that distinction as the deciding factor, and the README does not document a fully offline mode.

Second, the process model is manual. There is no daemon, no service manager integration, and no documented auto-restart. The README's own advice is tmux, screen, or a Windows startup task. An assistant that is supposed to support you around the clock depends on you keeping a terminal session alive.

Third, the icon launcher's `.env` location is a real footgun. A terminal launch and an icon launch read `.env` from different directories, so a working terminal setup can silently lose its configuration when you switch to double-clicking. The README states the rule but does not offer a way to point the launcher at an arbitrary env file.

Finally, the plugin set is presented as a starting point, not a finished catalogue. The README says "today" when listing the accounting system, wiki and SEC-filings reader, which reads as an acknowledgement that the registry is early. If the plugin you need is not in that list, the README does not describe a no-code path for creating one; building a plugin is a TypeScript job inside the monorepo.

MulmoClaude compared with a hosted assistant or a plain chat client

The obvious alternative is a hosted assistant product, where you sign in and the vendor operates the storage, the sync and the uptime. The difference is not features, it is where the accumulated context lives and who can take it away. A hosted product optimises for zero setup and continuous availability; MulmoClaude optimises for the workspace being a directory you can copy, diff and back up. If your main complaint with hosted assistants is that you cannot export what they learned about you, that is the gap MulmoClaude targets.

The second alternative is a plain chat client wired to the Claude Code CLI or an API key. That gets you conversation and nothing else. MulmoClaude's distinguishing mechanism is that chat summons a GUI: the README lists markdown documents, ECharts visualisations, forms, wikis, spreadsheets and 3D scenes, with the plugin registry deciding which surfaces exist. A chat client has no registry and no schema-driven collections, so the output of a session is text you copy somewhere else rather than a record that persists in a workspace.

The third comparison is against no-code app builders. Those usually run in the vendor's cloud and produce apps you access through the vendor. MulmoClaude's README pitches the opposite: you describe the small app you want in everyday words, and it is built for an audience of one, living in your workspace. The trade-off is that you inherit the runtime, the prerequisites and the maintenance yourself.

Maintenance, licence and what upgrading costs you

The project is MIT licensed, stated in both the README badge and package.json. In practice that means you can read, modify and redistribute the code, and the monorepo is structured for it: workspaces under packages/, a plugins directory, and published sub-packages such as @mulmoclaude/shapescript-plugin. This is a description of the licence terms, not legal advice; if you plan to redistribute a modified build, read the LICENSE file yourself.

The maintenance picture is current. The repository is not archived, the last push was on 2026-09-15, and v1.17.0 shipped the same day with per-chat model selection, code-block copying and 3D export to GLB and STL. Release cadence on the plugin side is faster still, with two shapescript-plugin releases inside two days. That pace is a cost as well as a benefit: the README already tells you to re-run `create-shortcut` after upgrading, and the launcher sync and published-dependency checks in package.json (`check:launcher-sync`, `check:published-deps`) exist because keeping the launcher, the monorepo and the published packages aligned is work the maintainers have automated for themselves.

For a source install, the upgrade path is a git pull plus `yarn install`, and the codegen step runs automatically through `predev` and `prebuild`. There is no documented database migration step, which is consistent with the plain-files design, but it also means the README does not document rollback if a new version changes how a workspace file is interpreted.

Editorial conclusion

Adopt MulmoClaude if you already pay for Claude Code and want an assistant whose memories, collections and generated apps sit as plain files in a workspace you control. Skip it if you cannot keep a Node process running, will not install and authenticate the Claude Code CLI, or need a hosted service your whole team shares. Before committing, confirm three things on your own machine: that `npx mulmoclaude@latest` reaches the chat UI at http://localhost:3001, that a plugin you care about (the wiki, or the accounting plugin) actually loads, and that you are comfortable with the fact that closing the terminal stops the server unless you launch it under tmux, screen, or a Windows startup task.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. receptron/mulmoclaude on GitHub
5. Releases