# Config Backups

Codeman keeps timestamped copies of the files that hold what you have customized, so a bad
write, a hand edit or a botched restart can be undone. It is on by default, needs no setup,
and everything about it (where the copies go, how many are kept, how long) is a setting.

## What is backed up

A fixed list of files from the data directory (`~/.codeman/`, or the directory of the
[instance](Core-Concepts#instances) you run):

| File | What it holds |
| ---- | ------------- |
| `settings.json` | Your preferences that sync across devices, including model and CLI settings. |
| `clis.json` | CLI enable/disable and custom CLI entries. |
| `custom-model-hosts.json` | Saved custom model endpoints. **Holds API keys.** |
| `webhook.json` | Webhook notification target. |
| `intents.json` | Read My Mind per-case profiles. |
| `linked-cases.json` | Registered cases. |
| `remote-hosts.json`, `remote-cases.json`, `docker-hosts.json`, `docker-cases.json` | Remote SSH and Docker overlay configuration. |
| `webviews.json` | Saved dashboard URLs. |
| `push-keys.json` | Web-push keys (regenerating them drops every device's subscription). |
| `users.json` | Multi-user accounts. **Holds password hashes.** |
| `.env` | Credentials the TUI client reads. **Holds a password.** |

Only files that exist are included. This is an allowlist: nothing else in the data
directory is ever copied.

**Not backed up:** `state.json` (sessions, and also cron jobs and respawn presets: it is rewritten
with every session event, so it would bury the real changes), logs, `mux-sessions.json`, the hook
secret, Docker seeds and caches. Back `state.json` up with your normal file backups if you rely on
cron jobs.

## When a backup is made

- **At startup**, so the state the server found is always on record.
- **Whenever the content changes.** The files are read and hashed every five minutes; a new
  backup is written only if the set differs from the latest backup. An idle server writes
  nothing, and the history is one entry per real change rather than one per timer tick.
  A field a file rewrites on its own is not a change, and the comparison looks through it (the
  snapshot still stores the file exactly as written, and a restore puts those fields back as they
  were): `custom-model-hosts.json` `lastDiscoveredAt` (the model-discovery poll, every five
  minutes), `users.json` `lastLoginAt`, `settings.json` `lastUsedCase`, `intents.json`
  `recentPrompts` and `updatedAt` (every captured prompt) and `docker-cases.json`
  `lastClaudeSessionId` (a Docker case's conversation id after a `/clear`). Without that, every
  tick looked like an edit and 20 copies covered only about 100 minutes. So Compare shows
  `intents.json` as unchanged when only prompts differ, yet a restore drops the prompts captured
  since.
- **On demand**, with **Back up now** (always writes one, even if nothing changed).
- **Before a restore**, as a `pre-restore` safety copy of the files about to be replaced.

## Where they go and what they are called

The default folder is `<data dir>/backups/config` (`~/.codeman/backups/config`). You can point
it anywhere with an absolute path (a leading `~` is expanded). A path that is not absolute, or
that is the data directory itself, falls back to the default.

Each backup is one folder named for the moment it was made, in the server's local time:

```
~/.codeman/backups/config/
  cfg-20261011-120305/
    manifest.json        id, createdAt (epoch ms), reason, appVersion, SHA-256 + size per file
    settings.json        the original file names, unchanged
    clis.json
    custom-model-hosts.json
    ...
  cfg-20261011-123012/
  cfg-20261011-123012-2/   a second backup in the same second gets -2, -3, ...
```

| Part | Meaning |
| ---- | ------- |
| `cfg-YYYYMMDD-HHMMSS` | Date and time (server local time) the backup was made. A collision in the same second gets `-2`, `-3`, … |
| `manifest.json` | The record of the backup: `reason`, `appVersion`, and a SHA-256 and size for every file. |
| `reason` | `startup`, `auto` (a change was detected), `manual` (Back up now) or `pre-restore`. It is in the manifest and the Settings list, not in the folder name. |
| `.tmp-…` | A backup being written. It is renamed into place when complete and is never listed. |

A folder counts as a backup only if its name matches that pattern **and** it has a valid
`manifest.json`. That is what makes it safe to point the folder at a directory that also holds
other things.

## Retention

Two limits, applied after every backup:

| Setting | Range | Default | Meaning |
| ------- | ----- | ------- | ------- |
| **Keep this many backups** (`configBackupKeepCount`) | 2 – 500 | 20 | Keep the newest N; older ones are removed. (1 is not offered: every change would delete the state before it.) |
| **Delete backups older than (days)** (`configBackupKeepDays`) | 0 – 3650 | 30 | Also remove a backup once it has been replaced for longer than this. `0` means no age limit. |

Both apply together. Three guarantees:

- **The newest backup is never removed**, whatever the numbers say, so there is always one to
  go back to.
- **Only folders Codeman made are ever removed**, never anything else that happens to live in a
  custom folder.
- **Age counts from when a backup was replaced**, not from when it was made. Backups are made on
  change, so a config that stays the same for months has one backup whose own date keeps
  ageing; it is the copy you need the day something goes wrong, so it stays until a newer one
  has existed for longer than the limit.
- Because backups are made on change, 20 backups reach back across 20 *changes*, however long
  that took, not 20 timer ticks.

## Settings → System → Config backups

| Control | Setting | Default |
| ------- | ------- | ------- |
| Back up my configuration | `configBackupEnabled` | On (absent means on) |
| Backup folder | `configBackupDir` | empty = `<data dir>/backups/config` |
| Keep this many backups | `configBackupKeepCount` | 20 |
| Delete backups older than (days) | `configBackupKeepDays` | 30 |
| **Back up now** | | |
| The list, with **Restore**, **Compare with current** and **Changes in this backup** per entry | | |
| **Compare** … with … **Show changes** | | |

The settings are saved server-side and read fresh, so a change applies on the next pass. The
list and **Back up now** use the **saved** folder and retention: apply your edits first.

## Restoring

From the list, press **Restore** on a backup and confirm. Codeman then:

1. **Verifies** every file in the backup against the SHA-256 in its manifest. If any file is
   missing or does not match, nothing is changed and you get an error.
2. **Takes a `pre-restore` backup** of the files about to be replaced, so a restore can itself
   be undone.
3. **Replaces each file atomically** (written beside it, then renamed) with mode `0600`.

Only the tracked names are ever written, whatever a manifest lists.

Settings are re-read on the next request, so reload the page. `.env` and `push-keys.json` are
read once per process: **restart Codeman** for those to take effect (the response lists which).
`clis.json` is reloaded by the restore itself and `users.json` is re-read within a second. Restoring `settings.json` also does not re-run the switches
that saving in Settings applies at once (file watchers and the like), so those apply after a
restart, and `settings.json` is listed with the restart-required files. A restore does not touch
running sessions.

When the backup folder is shared (a synced folder used by two machines, or prod and a beta),
each snapshot records a random id that the instance made once and keeps in its data directory
(`config-backup-id`; not the hostname, which a Docker container changes on every recreate). Every
instance only snapshots, lists, prunes, compares and restores its own. Deleting that file makes
the instance a new owner, and its earlier snapshots stop being listed (they stay on disk).

You can also restore by hand: the files in a backup folder are the originals, so copying one back
over the file in the data directory is equivalent (stop Codeman first if you are replacing
`clis.json` or `users.json`).

## Comparing backups

Before you restore, or to find out what changed and when, use **Compare** in the list:

- **Compare with current** on a backup shows what differs between that backup and the config
  running now. A restore puts back the files the backup holds; files created since are left as
  they are, and the restore response names them (`untouched`).
- **Changes in this backup** shows what differs between the backup before it and this one.
- The **Compare … with … Show changes** pickers compare any two backups, or a backup with the
  current config.

Each file that differs is listed with its changed keys (`theme.mode`, `tags[1]`, a variable name
in `.env`) as before → after, plus files that appeared or vanished between the two states. Files
that are the same are listed on one line. A file that is not JSON shows only that it differs, and
a file with more than 200 changes is cut short, so use the files themselves for a full diff. The
self-rewritten fields listed under "When a backup is made" are not counted as changes.

**Credential values are never shown.** `.env`, `users.json`, `push-keys.json`, `webhook.json` (the
URL is a bearer secret) and `intents.json` (captured prompts) list only the names that changed, and in every other file a key that looks like a token, secret, password,
credential or key is shown as "changed" without its value. URL values lose any `user:password@`,
query and fragment.

## Security

- Some tracked files carry credentials (`.env`, `users.json`, `custom-model-hosts.json`,
  `push-keys.json`). Each backup folder is mode `0700` and its files `0600`, so the default
  location exposes nothing the data directory does not already.
- **A custom folder is your decision.** Putting it on a shared drive, a synced folder or a
  network share copies those credentials there, with whatever permissions that location has.
  Choose a private location, or turn the feature off if you cannot.
- In [multi-user mode](Multi-User-Mode) all of it is admin only: the list, Back up now,
  Restore and Compare.
- Listing returns file names and sizes, never contents. A comparison returns changed values but
  never a credential's (see [Comparing backups](#comparing-backups)).

## HTTP API

```bash
API=http://localhost:3000
curl -s "$API/api/config-backups" | jq                                  # settings, folder, list
curl -s -X POST "$API/api/config-backups" | jq                          # back up now
curl -s -X POST "$API/api/config-backups/cfg-20261011-120305/restore" | jq
curl -s "$API/api/config-backups/diff?from=cfg-20261011-120305" | jq   # that backup vs the running config
curl -s "$API/api/config-backups/diff?from=cfg-20261011-120305&to=cfg-20261012-090000" | jq
```

See [HTTP API](HTTP-API) and the endpoint reference in `docs/api-reference.md`.

## Troubleshooting

- **The list is empty.** None of the tracked files existed yet, or backups are turned off. Press
  **Back up now**.
- **"Backups are not available here".** You are not an admin in multi-user mode.
- **No new backup after I changed a setting.** Changes are picked up within five minutes; **Back up
  now** takes one immediately.
- **A restore said a file does not match its checksum.** The backup was altered or damaged on
  disk. Nothing was changed; restore an earlier one.
- **The backups folder is growing.** Lower **Keep this many backups**. Each backup is a few
  kilobytes, but `custom-model-hosts.json` and `intents.json` can be larger.
- **I want my own off-machine copy.** Point the folder at a location your backup tool already
  covers, mind the Security note above, and keep **Keep this many backups** high enough that
  your tool sees each one.

## Read next

- [Settings Reference](Settings-Reference) - where the controls live.
- [Core Concepts](Core-Concepts) - what is on disk.
- [Security](Security) - what is protected and how.
- [Troubleshooting](Troubleshooting) - "my settings were reset".