# MulmoClaude keeps your assistant's memories in your workspace, not on a service

> A local-first assistant platform where capabilities are plugins in one registry, chat summons the right GUI for each task, and everything the assistant accumulates stays as plain files on your machine. The launcher is one npx command, and the interesting edges are where an icon launch and a terminal launch read different files.

**receptron/mulmoclaude** — Nurture your own AI assistant on your own computer. Local-first and MIT: memories, data and apps stay as plain files in your workspace. Chat summons the right GUI — wiki, spreadsheet, chart, form, 3D. Build small apps for an audience of one, no programming required.

- Repository: https://github.com/receptron/mulmoclaude
- Website: https://www.npmjs.com/package/mulmoclaude
- Stars: 350 · Forks: 60
- Language: TypeScript
- License: MIT
- Published: 2026-09-15 · Updated: 2026-09-15 · Language: en
- Canonical page: https://hysenlabs.com/projects/receptron-mulmoclaude

## npx mulmoclaude@latest boots a server on port 3001 and asks for nothing else

The whole launch is one command.

```bash
npx mulmoclaude@latest
```

It boots the server and opens http://localhost:3001 in a browser. There is no wizard, no account step and no configuration file required to get a first chat on screen.

What it does depend on is listed as prerequisites, and two of them are not optional in practice. Node.js 22.19 or newer is the runtime. Claude Code must be installed and authenticated, which means running `claude` once to complete OAuth, and that step is where your account choice gets made.

ffmpeg is required only if you generate videos, and the three install lines differ per platform.

```bash
brew install ffmpeg
apt install ffmpeg
winget install Gyan.FFmpeg
```

Two further tools are optional. Docker Desktop enables sandbox mode and is recommended though not required, and whisper.cpp enables local voice input for dictating chat messages but is macOS only.

The one operational catch is in how you leave it running. Closing the terminal stops the server, so the documented answers are tmux or screen on macOS and Linux, or a startup task on Windows. That is the difference between a tool you use and a tool you set up once.

## An icon launch reads ~/.env while a terminal launch reads the directory you were in

The shortcut generator exists so you can stop opening a terminal, and it introduces the sharpest edge in the project.

```bash
npx mulmoclaude@latest create-shortcut
```

On macOS it writes MulmoClaude.app into /Applications, or ~/Applications when that is not writable, with --dir to choose a path and --yes to skip the prompt. Double-clicking checks the prerequisites, shows a progress page while the server starts, and opens the app when ready; if the server is already running it just opens the browser instead of starting a second one. When something is missing it names which one, and what to run, in your system language, and its log is at ~/Library/Logs/MulmoClaude/launcher.log.

Now the edge. A terminal launch reads .env from the directory you launched in. An icon has no such directory: macOS starts apps in /, and Windows starts them wherever the shortcut points, so the icon launch reads ~/.env in your home directory instead. Same application, two different configuration files, and no documented warning beyond a note explaining why.

On Windows the same command writes a Start Menu shortcut, keeps its own launcher files under %LOCALAPPDATA%\MulmoClaude, and opens no console window. Re-run the command after upgrading, because the shortcut carries its own copy of the launcher and will otherwise run the old one.

## Capabilities are plugins in one registry, and Claude is the controller across them

The architectural claim sits in MANIFEST.md, titled How AI-Native Applications Should Be Built, and the short version is in the README: this is an AI-native application platform where capabilities are plugins in a single registry and Claude acts as a universal controller composing across them.

What is in the registry today is worth naming, because it says where the effort went: a full accounting system with real server-side bookkeeping logic, a personal wiki, and an SEC-filings reader. Those are not prompts wrapped around a UI. The accounting capability keeps its books on the server side, which is the difference between a demo plugin and one that holds state.

The second half of the mechanism is that chat does not only return text. It summons the right surface for the task: markdown, charts, forms, wikis, spreadsheets or 3D scenes. That is why the entry point is called a canvas in the examples table, and why the protocol matters as much as the plugin set.

The monorepo layout backs the registry claim. package.json declares four workspace globs, packages/*, packages/bridges/*, packages/plugins/* and packages/services/*, which separates chat bridges, plugin implementations and long-lived services into different package kinds, and the plugin barrels are code-generated with plugins:codegen plus a check mode that fails when they drift.

## A wiki page with [[links]] is the long-term memory format, and collections are schema-driven

The capabilities are demonstrated as a table of requests and what comes back, and reading it tells you what the data model is.

Asking for a project proposal gives a rich markdown document in the canvas. Asking to chart last quarter's revenue gives an interactive ECharts visualization. Asking for a trip plan for Kyoto gives an illustrated guide with images, which is where the optional GEMINI_API_KEY in .env.example comes in. Asking to set up a todo list gives a schema-driven collection with a kanban board, so structured data arrives as a board rather than as prose.

Ingesting an article by URL gives a wiki page carrying [[links]], and that is the memory mechanism: pages that reference each other by name, accumulated in a personal wiki that Claude builds and maintains itself. The framing in the README is that the wiki is a place to accumulate memories, and collections and plain files are a place to keep data.

Asking to schedule a daily news digest produces a recurring task that runs automatically, which is the piece that turns the assistant from a chat window into something that acts on a schedule.

Because all of it is plain files in your workspace, the exit path is unusually cheap. Nothing here needs a migration to read your own history.

## The relay carries messages in transit, and the workspace stays on your machine

The assistant is not tied to the desk, and the way it is not tied to the desk is the security story.

You can log in from a phone, or from a messaging app you already use, and reach the same assistant running on your computer. The relay server exists to carry messages in transit. Your memories, data and apps never leave your computer.

That sentence carries more weight than a hosting diagram would, because the alternative for most assistants is that the accumulated context lives on someone else's service, and the README makes that argument explicitly: the substance of an assistant is not the model, the model is the engine, and what makes an assistant valuable is how much it knows about you, which is exactly the thing that gets harder to leave the longer you use it.

The workspace being plain files follows from the same decision. You can read what the assistant knows about you with a text editor, copy it, and remove it, and none of that requires asking anyone's permission.

The trade is that the phone access depends on a relay being reachable and on your own machine being up. There is no hosted fallback described for that case.

## Eight locales ship, and .env.example still documents two

The user interface supports eight locales: English, Japanese, Simplified Chinese, Korean, Spanish, Brazilian Portuguese, French and German. The default is auto-detected from the browser or OS language, and an explicit choice goes in .env as VITE_LOCALE with one of ja, zh, ko, es, pt-BR, fr or de.

Two details matter more than the list. The locale is picked at build or dev time rather than at runtime, so changing it means restarting yarn dev, and it is not a setting you can flip from the running app.

The second detail is a documented gap. The .env.example file in the repository still says the supported set is "en" (default), "ja", which does not match the eight locales the README advertises and the eight README translations sitting in the repository root: README.ja.md, README.zh.md, README.ko.md, README.es.md, README.pt-BR.md, README.fr.md and README.de.md. Either the comment is stale or the variable is validated somewhere the example file does not show. Find out which before you file anything about a missing language.

There is also an optional local voice path: whisper.cpp on macOS enables dictating chat messages without sending audio anywhere.

## MULMOCLAUDE_TRUSTED_ORIGINS is a verbatim match, and postinstall repairs node-pty permissions

Two implementation details say more about how this codebase is run than the feature list does.

The first is the CSRF guard. .env.example carries a commented block explaining the allowlist for cross-origin state-changing requests, POST, PUT, PATCH and DELETE. Localhost is always allowed. Beyond that the value is a comma-separated list matched verbatim against the Origin header, including scheme and port, with no trailing slash, and the literal string null is rejected even if you list it, because that is what browsers send from sandboxed iframes, file:// and data: pages. The example given is granting a LAN device such as an iPad reach to the dev server.

```bash
MULMOCLAUDE_TRUSTED_ORIGINS=http://192.168.1.42:5173
```

The second is the postinstall hook, which runs a script to fix node-pty permissions, and that tells you the terminal bridge is a native dependency rather than a pure JavaScript one. Around it sit the consistency checks the repo enforces on itself: a codegen check for plugin barrels, a launcher sync check, a published dependency check, a changelog-ships check, a doc link check, a plugin Tailwind source check, and knip for unused code.

Release notes in the same spirit name the failures users hit. v1.26.2 shipped on 2026-09-28 with getSchema flagging an unapplied schema change and a gui-chat-protocol bump to 2.1.0, and v1.26.1 the day before was a chat that failed to start being released again. The package version is 1.26.2, engines demand Node 22.19 or newer, and the licence is MIT.

## Conclusion

Adopt MulmoClaude if you want an assistant whose accumulated knowledge lives in files you can read, back up and delete, and if you are willing to keep a Node server running and to authenticate the Claude Code CLI once. Do not adopt it if you need a hosted service, because the whole value proposition is that nothing but messages is ever relayed off your machine. Verify three things first: whether Claude Code is authenticated on the account you expect, where your .env actually sits for the launch method you will use, since an icon reads ~/.env while a terminal reads the current directory, and whether the eight advertised UI locales match the two your .env.example documents. The licence is MIT, v1.26.2 shipped on 2026-09-28 with getSchema flagging unapplied schema changes, and the last push was on 2026-10-01.

## FAQ

### How do I start MulmoClaude on my own computer?

Run npx mulmoclaude@latest. The launcher boots the server and opens http://localhost:3001. You need Node.js 22.19 or newer and the Claude Code CLI installed and authenticated by running claude once to complete OAuth.

### Where does my data and memory actually live in MulmoClaude?

In your own workspace as plain files: a personal wiki of linked pages built and maintained by Claude, schema-driven collections and feeds for data, and the small apps built for you. Nothing but messages in transit is relayed off your computer.

### What does the create-shortcut command do in MulmoClaude?

It writes MulmoClaude.app to /Applications on macOS, or ~/Applications when that is not writable, with --dir and --yes as options. On Windows it writes a Start Menu shortcut and keeps launcher files under %LOCALAPPDATA%\MulmoClaude.

### Which languages does the MulmoClaude interface support?

Eight locales are supported, auto-detected from the browser or OS language, and set explicitly with VITE_LOCALE in .env. The locale is picked at build or dev time, so yarn dev has to be restarted after changing it.

## Sources

- [License: MIT](https://github.com/receptron/mulmoclaude/blob/main/LICENSE)
- [Project website](https://www.npmjs.com/package/mulmoclaude)
- [README](https://github.com/receptron/mulmoclaude/blob/main/README.md)
- [receptron/mulmoclaude on GitHub](https://github.com/receptron/mulmoclaude)
- [Releases](https://github.com/receptron/mulmoclaude/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/receptron-mulmoclaude