Most AI agent setups still look like one chat window with a longer leash. That is the wrong shape for work that can be split up. One agent investigates, another changes code, a third checks the result, and somebody still needs to decide whether a shell command should run.

Munder Difflin is a local desktop harness built around that problem. It wraps the terminal CLIs you already use, starts them as separate processes, gives them mailboxes and memory, and puts a supervisor in the middle. The useful part is not the office-floor animation. It is the control loop underneath: route work, keep agents from sharing a Git index, record cost, and ask a human before spending money or doing something destructive.

Munder Difflin local multi-agent office

The project published v0.4.5 on August 22, 2026. That release matters for a practical reason: the README says it fixed three failures that are easy to miss in a multi-agent system. Cost reporting now comes from the durable ledger instead of a counter that reset when the app restarted, Apple Silicon embeddings are pinned to CPU after CoreML returned NaN vectors, and an inbox wake watchdog prevents messages from sitting unread. Those are not cosmetic fixes. They are the sort of failures that make an autonomous setup look busy while quietly doing nothing useful.

The setup that actually works

This is a source install, not a magic one-click cloud service. The official README gives a short path:

git clone https://github.com/chaitanyagiri/munder-difflin.git
cd munder-difflin
npm install
npm run dev

That is 3 commands after cloning. npm install rebuilds the node-pty native module against Electron's ABI. If it fails after an Electron upgrade, run it again rather than debugging the wrong layer. On macOS, you also need the Xcode Command Line Tools. On Linux and Windows, you still need a working C/C++ toolchain for the native addon.

The machine needs Node.js 18 or newer and at least one supported CLI on your PATH. The current README lists 12 providers: Claude Code, Antigravity, OpenAI Codex, xAI Grok, Kimi Code, Gemini CLI, Qwen, OpenCode, Crush, pi.dev, GitHub Copilot CLI, and Cursor. That list is the reason to try a harness like this instead of replacing every tool you already know. Munder Difflin is acting as a coordinator around those processes, not pretending that one model is good at every job.

After the first launch, the onboarding wizard takes you to the office floor. Add one agent first. Do not start with a ten-agent mission. Confirm that the CLI starts, that the registered working directory is correct, and that you can stop the process. Then add a second agent with a separate role, such as a test reviewer. A small two-agent run tells you more than a spectacular demo with a dozen avatars.

The local model path is also practical. The README lists Ollama, LM Studio, and vLLM as optional engine endpoints, alongside provider keys. That lets you use a paid CLI for difficult reasoning and a local model for cheap classification or file inspection. The project says it works with the subscriptions you already pay for and their hourly limits, but that is not a promise of unlimited parallel work. Provider limits still apply, and several agents can burn through an allowance faster than one interactive session.

The architecture is easier to understand if you ignore the pixel office. Each agent is a real terminal process running in a pseudo-terminal. The event plane handles hooks, routing, memory, mailboxes, and the supervisor. The terminal plane handles PTY input and output. A typed Electron context bridge sits between the renderer and the main process, while filesystem and Git operations are brokered by the main process.

That split solves a boring but expensive failure mode. Agents do not all commit directly into the same Git index. They write plain files into their own outboxes, the router delivers messages to inboxes, and the main process acts as the single committer. Optional Git worktrees add another layer of isolation for parallel branches. This will not prevent a bad edit, but it does reduce the chance that two agents turn index.lock into the entire team's afternoon.

Where the safety model stops

Local first does not mean harmless. The official security policy says the app opens 1 local Unix domain socket for its hook server and no remote network listener. It also says renderer-to-main IPC uses a typed context bridge, Node integration is disabled, context isolation is enabled, and filesystem and Git calls are sandboxed and path-validated under a registered agent working directory.

Those are useful boundaries. They are not a sandbox for the commands your agents run. A Claude, Codex, or local CLI process can still read and modify everything that the registered directory and its credentials allow. If you point the harness at your home directory, you have chosen a very large trust boundary. Start with a disposable repository, a separate Git identity, and no production secrets in the environment.

The supervisor helps with a different class of risk. The README describes human gates for spend, scope changes, and destructive operations, plus a steer, constrain, stop circuit breaker for agents that loop or run over budget. These gates are valuable because an autonomous process needs an interrupt path. They do not prove that every tool call is safe. Treat them as a review queue, not as a replacement for least privilege.

Telemetry deserves the same plain reading. The project says official builds send anonymous events such as app opened, agent spawned, and feature used, while excluding prompts, code, file paths, and agent output. It documents a Settings opt-out, DO_NOT_TRACK, and a source-build route with no telemetry key. That is a reasonable disclosure for a prototype, but teams with strict policies should read TELEMETRY.md and build from source before connecting sensitive work.

The other limit is maturity. The repository labels itself a working prototype. Older releases had a usage-limit guard that could hold agents after a limit was reached. The current release removes that guard, but the fact that it existed is a reminder to watch the first few runs. Turn on budgets. Keep the activity log open. Check the ledger after a restart. If a worker is supposed to be waiting for a human and instead keeps producing output, stop it rather than assuming the visual state is correct.

What I would run first

I would use this as a local coordinator for work that has clear handoffs: one agent reads an issue and writes a plan, another implements it in a worktree, and a third runs tests and reports failures. I would not hand it an open-ended instruction like “improve the whole codebase overnight.” That creates too much room for silent scope expansion, and no office metaphor fixes an ambiguous job.

A sensible first mission looks like this:

  • Register a disposable repository, not a home directory.
  • Add one implementation agent and one review agent.
  • Give the reviewer read-only expectations in the task, even if the underlying process has broader filesystem access.
  • Set a budget and require approval for package installs, deletions, network changes, and pushes.
  • Let the implementation agent produce one small pull request.
  • Check the transcript, cost ledger, inbox delivery, and Git history before increasing parallelism.

The decision is simple. If you already use several terminal agents and keep losing track of who changed what, a local supervisor can be worth the Electron overhead. If you only need autocomplete and occasional code generation, this is too much machinery. If you need a hard security boundary, do not confuse “no remote control plane” with container isolation. Add that boundary yourself with a VM, a locked-down user, or a disposable development host.

Munder Difflin's best idea is not that agents should look like office workers. It is that an agent fleet needs ordinary engineering controls: queues, budgets, logs, separate workspaces, and a person who can say stop. The project is fresh and still has prototype edges, but those controls are more useful than another chatbot tab.

Sources