Install mm on macOS

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73

# Install `mm` on macOS

```bash
# download the binary release in https://rickub.com/bots-garden/mini-me/releases
VERSION=0.2.1
curl -fsSLO "https://rickub.com/bots-garden/mini-me/releases/download/v${VERSION}/mm-${VERSION}-darwin-arm64"
chmod +x ./mm-${VERSION}-darwin-arm64
xattr -cr ./mm-${VERSION}-darwin-arm64
sudo rm -f /usr/local/bin/mm
sudo cp ./mm-${VERSION}-darwin-arm64 /usr/local/bin/mm
```

## Use `mm` in a Docker Sandbox (the two kits)

Instead of installing the binary, `mm` can run inside a [Docker Sandbox](https://docs.docker.com/ai/sandboxes/): every command the model runs and every file it edits then happens in a container, on your mounted project. Two kits are published on Docker Hub at mm's version; each one brings the `k33g/mm-sandbox` image with `mm` in it, so nothing is built on your Mac.

| Kit | For |
|---|---|
| `k33g/mm-tui:0.2.1` | the window mode (`mm -tui`) in your terminal |
| `k33g/mm-acp:0.2.1` | an editor that speaks the Agent Client Protocol (Zed, …) |

You need Docker Desktop with the `sbx` command, and your model server (Docker Model Runner or llama-server) running on the Mac. Inside the sandbox, `localhost` is the sandbox itself: `agent.dmr.yaml` already falls back to `host.docker.internal`, which reaches the Mac.

### Window mode: `mm-tui`

From the project you want `mm` to work on:

```bash
cd /path/to/your/project
sbx kit inspect k33g/mm-tui:0.2.1                  # optional: what the kit declares
sbx run k33g/mm-tui:0.2.1 . -- agent.dmr.yaml
```

What follows `--` is `mm`'s own command line (here the configuration file, relative to the project). `sbx ls` lists the sandboxes; `sbx run --name <name>` re-attaches to one.

### From an editor: `mm-acp`

Create the sandbox once, from the project the editor will open, with the configuration file baked in:

```bash
cd /path/to/your/project
sbx create --name mm-acp k33g/mm-acp:0.2.1 . --kit-arg config=agent.dmr.yaml
```

Then register it in Zed's `settings.json`:

```json
{
  "agent_servers": {
    "mini-me (sandbox)": {
      "type": "custom",
      "command": "sbx",
      "args": ["exec", "-i", "mm-acp", "mm", "-acp"]
    }
  }
}
```

If Zed cannot find `sbx`, put the absolute path given by `which sbx` in `"command"`. One sandbox per project: give each one its own `--name` and its own entry in Zed. `sbx rm mm-acp` removes a sandbox; your project directory is not touched.

### The v3 kits

The same two kits also exist for the kit specification v3, in `docker-sbx-v3/` (not published yet, and not yet tried with `sbx`). From a clone of this repository:

```bash
cd /path/to/your/project
sbx run /path/to/mini-me/docker-sbx-v3/kits/mm-tui . -- agent.dmr.yaml
sbx create --name mm-acp /path/to/mini-me/docker-sbx-v3/kits/mm-acp . --kit-arg config=agent.dmr.yaml
```

With the v3 kits, give `config` a path relative to the project: the workspace is mounted at `/home/agent/workspace`, so a `/Users/…` path does not exist inside the sandbox.

Full guides: [Run mini-me in a Docker Sandbox](docs/en/how-to/run-in-a-docker-sandbox.md) (v2 kits, MCP, variants) and [Run mini-me with the v3 sandbox kits](docs/en/how-to/run-with-sandbox-kits-v3.md).