Coming from claude-mpm

What carries over

The shape of the work is the same. A PM session orchestrates and delegates; specialised agents do the implementing; skills are reusable instruction packs; an output style decides how the PM writes back to you. If those four words already mean something to you, you know how to drive tm.

That parity is deliberate rather than incidental. tm launch runs the full deployment sequence — instructions, agents, skills, MCP config — into the project and then starts or attaches the session in your current terminal, which is the same single-command experience you already have. The source comment on that subcommand says it plainly: it behaves like running claude-mpm.

A supervising daemon, not a process per session

claude-mpm runs inside the session it manages: start it, and its lifetime is that session's lifetime. trusty-mpm inverts that. A long-lived daemon holds the project registry and the session roster, and sessions are things it configures, launches, and supervises. Close a terminal and the daemon still knows what is running; restart the daemon and the roster survives, because it is on disk rather than in a process.

Two more daemons come with it. Together they are what a session reads from and writes to, and each one is also an MCP server, so a session reaches them through tool calls rather than by shelling out.

Every one of those is local-only. trusty-mpm and trusty-search bind loopback HTTP and additionally reject requests whose origin is not the machine itself; trusty-memory's daemon has no network listener at all — its transport is a Unix domain socket, reachable only to processes on the same host. Either way, a page you happen to have open cannot reach them.

Addresses are resolved from each daemon's discovery file rather than assumed, so a daemon that rebinds to a different port is still found. When one is unreachable the caller gets an error, not a silent timeout.

Sessions live in tmux

A tm session is a tmux session. That is not a convenience wrapper you can opt out of — it is how the daemon can keep a session alive while no terminal is attached to it, and how several sessions run at once without one window per session on your screen.

Names are derived rather than random. A session gets tm-<project>-NN — an explicit hint if you gave one, otherwise the repository name, otherwise the directory's own name — with a per-project serial so two sessions on the same project stay distinguishable. When a session does get its own git worktree, the worktree is named after the session, so a path like .worktrees/tm-trusty-tools-01/ tells you which session owns it without consulting anything.

Sessions also pause and resume — tm sessions pause and tm sessions resume — and finish with tm sessions decommission, which removes the session's worktree and branch together rather than leaving either behind.

Agents deploy per project, not into your global config

This is the difference most likely to surprise you, and it comes from a real incident. A shared global ~/.claude/agents is a single namespace every Claude Code tool writes into, and in July 2026 one tool's agents leaked into another tool's sessions. The fix was a rule: trusty-mpm never depends on the user's real ~/.claude, and never writes your live checkout.

The mechanism is one environment variable. tm launches Claude Code with CLAUDE_CONFIG_DIR pointed at a directory tm owns, so every ~/.claude path Claude Code would otherwise read resolves inside that directory instead. Your real ~/.claude — and whatever hooks, MCP servers, and agents another tool put there — is excluded outright rather than merged on top. Project-scoped content lands in the checkout's own .claude/ inside a workspace tm controls.

Memory and search per project

Memory is a palace: a named store scoped to a project rather than to a conversation, holding prose an assistant wrote and can recall later, alongside a knowledge graph of structured triples. A session reaches it through MCP tool calls at an address resolved from the daemon's own discovery file — never a hardcoded port, which is what used to make this silently fail when the daemon rebound.

Search is scoped the same way, and more tightly than you might expect. When a session is provisioned, its project gets a search index derived from the project's path, and that index id is pinned into the session's own .mcp.json. Every search the session runs is therefore already scoped — there is no ambiguity for the daemon to guess at, and a query cannot return results from the last project you worked on. When the session is decommissioned the index is marked for collection, so indexes do not accumulate.

Migrating your kuzu-memory data

If the memory server you were running is kuzu-memory, trusty-memory migrates it for you rather than leaving you to re-enter anything. trusty-memory migrate takes two targets, and they are independent: one rewrites configuration, the other moves data. Most people want both, in that order.

kuzu-memory — the configuration

Scans every .claude/settings.json and settings.local.json under your home directory, drops any kuzu-memory or kuzu_memory entry from the mcpServers block, and inserts a canonical trusty-memory one in its place. Unrelated keys survive, each write is atomic with a .bak alongside it, and a file already carrying a trusty-memory entry is left byte-for-byte alone — so running it twice is safe.

trusty-memory migrate kuzu-memory --dry-run
trusty-memory migrate kuzu-memory

kuzu-data — the memories themselves

Reads a kuzu-memory store.redb and imports it into a palace: every entity becomes a drawer, every relation becomes a knowledge-graph triple. There is no default source path — --from and --palace are both required, and the command errors naming the missing one rather than guessing. The palace is created if it does not exist yet. Re-running it changes nothing: drawer ids come from a stable hash of the entity id and the palace name, and an existing triple is skipped rather than duplicated.

trusty-memory migrate kuzu-data \
  --from ~/.open-mpm/memory/store.redb \
  --palace your-project --dry-run

--dry-run prints the schema it found and the plan without writing. --limit <N> caps how many entities are imported, which is the way to try it on a slice before committing to the whole store. Drop --dry-run to run it for real.

Where the work happens

By default a session runs on your project's main checkout — several sessions sharing one checkout is the normal arrangement rather than a hazard. What keeps that safe is a write boundary the harness enforces rather than asks for: a session standing in a main checkout may write documents and configuration there, and an agent it dispatches that needs to change source is granted its own git worktree instead.

tm launch --worktree opts the whole session into its own worktree when you want the live checkout left completely alone.