Storage and data

The workspace layout

A workspace is any directory you point Anymo at. All Anymo state for that workspace lives under .anymo/, which is gitignored:

<workspace>/
├── .anymo/
│   ├── events.db          # the event log: every run, append-only (SQLite, WAL)
│   ├── memory.db          # namespaced memory with proposed/approved/rejected status
│   ├── skills/            # saved skills, one YAML file each
│   ├── query/             # Query Fabric search index (SQLite, FTS5 when available)
│   ├── config.toml        # provider endpoint template (never keys)
│   ├── mcp.toml           # local stdio MCP servers
│   ├── runtimes.toml      # Runtime Bridge configuration (+ runtimes.example.toml)
│   └── setup-state.json   # first-run state the desktop app reads
├── plugins/               # plugin bundles (manifest, skills, hooks, mcp config)
├── reports/, artifacts…   # ordinary files the agent writes, inside the workspace only
└── your project files

events.db: the source of truth

Every meaningful state change in a run is an event: run created, plan created, agents started, provider requests, tool calls, approvals granted or denied, artifacts created, memory and skill proposals, completion or failure. The log is append-only and gap-free per run; current state is always derived by replaying it, never stored as a second mutable copy.

Storage is a SQLite database in WAL mode. The full event is stored as JSON with the envelope fields (run, sequence, type, timestamp, schema version) denormalized into indexed columns. Two backends exist behind the same trait: this SQLite store for persistence and an in-memory store for tests.

Practical consequences:

• Restart-safe. Quit, crash, or come back a month later: a run reconstructs exactly from its events. anymo show <run-id> prints the timeline; the app replays it read-only.
• Tamper-evident. Sequence numbers are 0, 1, 2, with conflicting appends rejected, so holes and races are detectable.
• Append-only corrections. Mistakes are corrected by appending a compensating event, never by editing history.

memory.db: reviewed memory

Memory is durable, namespaced key/value storage with an approval workflow. Each item carries a namespace, key, value, status, timestamps, and the run that proposed it. The namespaces are user, project, workspace, skill, and team_reserved (a placeholder for future team features).

• Writes arrive as proposed and only become trusted once approved; low-risk summaries may be saved pre-approved.
• Reads return the most recent approved value for a key. Proposed and rejected items never flow into runs.
• Values are redacted on the way in: machine-specific paths and secret-looking strings never persist.

How proposals are generated and reviewed is covered in Self-learning.

skills/: saved runs as YAML

Each skill is one YAML file: name, description, declared permissions, and steps with their tools and optional templated inputs. Because skills are plain files, you can read them, diff them, and version them. A skill's declared permissions are validated against the tools its steps use.

The search index

Query Fabric maintains its own SQLite index of redaction-safe documents drawn from your files, memory, skills, tools, artifacts, and events. It can always be rebuilt from scratch with anymo index, so it is a cache, not a source of truth. Internals are on the Query Fabric page.

Where secrets live (and where they never do)

Provider profile metadata is stored as JSON, but keys are never written into it; summaries expose only has_api_key. Keys never appear in events, logs, artifacts, the search index, or the UI, and rendered provider errors redact bearer keys and header values before they enter the log.

Workspace containment

All agent file access goes through a hardened workspace primitive rooted at the workspace directory:

• Paths are workspace-relative only; absolute paths and .. traversal are rejected, and symlink escapes are denied by canonicalizing against the workspace root.
• Reads and writes are size-capped (default 10 MiB) and binary-as-text is refused.
• Writes are atomic: staged to a temp file, then renamed.
• Stored paths are workspace-relative and redaction-safe; your absolute home path never reaches events, memory, or the UI.

Isolation for large swarms

In swarm transaction mode, workers do not write the shared workspace directly. Each worker gets an isolated overlay: file.write stages text patches against a snapshot, binary outputs become artifacts, and a verifier computes patch sets and conflicts before anything merges. The merge policy auto-merges only low-risk, non-conflicting creates; overwrites, large changes, and conflicts require approval; path or symlink escapes are denied outright. Merges are rollback-aware: if a later patch fails, earlier ones are restored.

Separately, the Runtime Bridge and the project harness run external jobs in managed Git worktrees, sibling *.anymo-worktrees/ directories, never your checkout. See Runtime Bridge.

Compaction artifacts

Long runs are compacted into structured continuation packets: constraints still in force, open loops, decisions, failures with evidence anchors, file touch maps, pending approvals, and next actions. Compaction writes separate CompactionArtifact records to SQLite and never deletes or rewrites event rows, so raw history stays intact while resume stays cheap. Details in Self-learning.

Portability and stability

There is no cloud sync and no hosted backend. Moving a workspace directory moves all of its Anymo state with it, except sealed secrets, which stay in the OS keychain of the machine that saved them.