lazy documentationv0.94Contents

The daemon and its clients

flowchart LR
  CLI[CLI] --> Daemon[Project daemon]
  Browser[Dashboard or Teams] --> Daemon
  MCP[Agent MCP server] --> Daemon
  Supervisor[Task supervisor] --> Daemon
  Daemon --> Rules[Task rules and transitions]
  Rules --> Store[(Task store)]
The CLI, web interface, agent tools, and supervisor all ask the daemon to apply task rules to the store

Each project has one daemon. It owns every rule and all the state; everything else is a client that asks it to act.

Clients ask the daemon to do things and never write the store themselves, so a rule such as "accept refuses while a blocking question is open" is the same on every surface. The daemon listens on loopback by default ([server] bind). See The daemon, the task container and the proxy.

The store

Tasks, sessions, turns, commits, comments, conversations and memory live in the project's store: by default a folder under ~/.lazy/<project-name>, or the [storage] external_path you set. It sits outside the repository, so it is never committed, and task containers are not given it.

Before a new lazy version first opens a store, lazy saves it as a verified compressed archive next to it and keeps the newest five ([storage] backup_keep). If the backup fails, the new version does not open the store. See Store backups.

On a single-person install, set backup retention in the project root's lazy.toml:

[storage]
backup_keep = 10

This keeps the newest ten verified backups beside the project's store. Lazy Teams manages this count itself and keeps five.

What the daemon also does

It runs the proxy (Agents and the proxy), reconciles task statuses against what is actually running (see The task state machine), and retries background work such as pushes and follow-through after an accept.