How to keep sessions and resume them

 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

# How to keep sessions and resume them

This guide shows how to make `mm` save every conversation of a project and get one back later, in the terminal and from an editor. It assumes `mm` runs with a configuration file you can edit.

## Steps

1. Turn the feature on in the YAML file:

   ```yaml
   sessions:
     enabled: true
     dir: .mm/sessions
   ```

   `dir` is relative to the project: the directory you start `mm` from in the terminal, the project the editor opened in ACP mode. Add `.mm/` to the project's `.gitignore`: a session file holds every command output the model read.

2. Start `mm` from the project directory. The banner now ends with a `sessions:` line:

   ```text
   sessions: saved under /work/project/.mm/sessions · 2 earlier — /resume to continue the latest, /sessions to list
   ```

   This run is a new session. Its file appears with the first question and is rewritten after every turn, after `/compact` and after `/new`.

3. List the project's sessions when you need one back:

   ```text
   > /sessions
   3 session(s) in /work/project/.mm/sessions — /resume <id> to continue one, /resume for the latest
   * 20260916-101530-4f2a9c1e  2026-09-16 10:15  2 turn(s)  add a /new command
     20260916-093012-77be01d3  2026-09-16 09:41  5 turn(s)  fix the skills loader
     20260915-181200-0a1b2c3d  2026-09-15 18:20  1 turn(s)  list the files
   ```

   The `*` marks the current session. Ids sort by creation time.

4. Continue one:

   ```text
   > /resume
   ↩️ resumed 20260916-093012-77be01d3 — 14 message(s), started with "fix the skills loader"
   ```

   A bare `/resume` takes the most recently updated conversation other than the current one, skipping empty ones; `/resume <id>` names one. From there, the model sees the resumed history — under the current system prompt — and every new turn is saved to that session's file. Nothing is replayed on screen: the one line says what came back.

## From an editor (ACP)

1. Keep `sessions.enabled: true` in the file `AGENT_CONFIG` points at. Each thread the editor opens is a session, saved under `<project>/.mm/sessions/<id>.json` from its creation.

2. Use the editor's **Reload Agent** (Zed) when the agent restarted or you changed its configuration. The editor sends `session/load` with the thread's id; `mm` reads the file back and replays the whole conversation — your questions, the answers, every tool call with the input it was given and the output it returned at the time. Nothing runs again. The thread then continues as before.

3. `/new` in a thread keeps the thread (the editor's session id) but the conversation so far is kept on disk under a new id, and the thread's own file starts over empty. `/sessions` and `/resume` do not exist over ACP: the editor is the one listing threads.

## Variants

- **One store for every project.** Give `dir` an absolute path. Sessions of different projects then share one directory; each file records its `cwd`.
- **A project you cannot write to.** The banner or the `[acp]` log says `not saved` with the reason; the conversation goes on unpersisted.
- **Compression.** A `/compact` or an automatic compression rewrites the file with the shortened history; a resumed or reloaded session starts from the summary, like the live one did.
- **Starting fresh on purpose.** Nothing to do: every start is a new session. The old ones only come back on `/resume` or on an editor reload.

## See also

- [Configuration reference](../reference/configuration.md) — the `sessions` keys
- [Slash commands reference](../reference/slash-commands.md) — `/sessions`, `/resume`, `/new`
- [ACP reference](../reference/acp.md) — `session/load` and what it replays
- [Why sessions work this way](../explanation/persistent-sessions.md)