ZeroClaw

Not restorable in one action: the `agents export` bundle omits memory, cron jobs and channels, and the complete whole-install copy must be made by hand; `zeroclaw agents import` is not implemented, so restoring means merging config.toml and copying directories into place.

• Agent portability docs
• Runtime state and persistence

The documented whole-install backup (config.toml, `.secret_key`, memory, sessions, cron, SOP runs and other state) contains everything that defines the agent. The per-agent `agents export` bundle deliberately omits memory, cron jobs, channels and secrets.

• Runtime state and persistence (backup and restore)
• Agent portability docs

ZeroClaw is a single self-hosted Rust binary under MIT OR Apache-2.0 with no hosted service, and it runs against local models via Ollama or OpenAI-compatible endpoints.

• Philosophy: You own it
• Ollama provider source
• ZeroClaw website

The agent has no identity of its own that contacts can verify: after migration they recognize it only through the channel accounts and A2A pairing tokens whose credentials travel with the install, relying on each platform. The daemon's Ed25519 key authenticates it to relays and the owner's own clients, not to counterparties.

• Agent filesystem & identity docs
• Secure transport docs
• A2A discovery docs

Docs state there is no telemetry, cloud tenancy or license server, and no license check or remote kill flag was found in the code.

• Philosophy: You own it
• ZeroClaw website

Tools, channels, memory, cron and SOPs are executed by the runtime, and a text tool-call parser lets models without native tool calling use them. Swapping to another provider, including local Ollama, keeps the capability set.

• Tool-call parser crate
• Ollama provider source
• Philosophy: Provider-agnostic

State is kept in TOML config, SQLite databases (sessions, memory, cron), JSONL logs and markdown files. Secrets and plugin state are encrypted with a local, owner-held key.

• Runtime state and persistence

Runtime-added prompt sections (e.g. Safety, Tool Honesty, tool list, runtime info) are defined in open source code, and full LLM request payloads can be logged via `log_llm_request_payload` (off by default).

• System prompt construction
• Logs & observability docs
• Philosophy: Minimal

There is no hosted service, account system or telemetry, so the vendor holds no data about the owner. Only the owner-chosen model provider receives content.

• Philosophy: You own it
• ZeroClaw website

Tool calls and messages are kept locally in sessions.db and leave with the install directory. The runtime trace is a rolling 200-event file and the docs describe persistence as best-effort, so the history is not guaranteed to be complete.

• Logs & observability docs
• Runtime state and persistence

Skills are human-readable markdown and scripts, and the runtime itself is open source. WASM plugins are loaded as compiled binaries, so their logic is not necessarily stored as readable source.

• Skills docs
• Plugins docs

No advertising or sponsored channel exists. Server-supplied MCP `pinned_resources` that enter the system prompt are owner-configured and flagged as a risk on export.

• Agent portability docs
• ZeroClaw website

Actions are not guaranteed a durable record: session-persistence failures are logged and the turn continues, and the runtime trace is best-effort. The config docs state that no production path records command execution in the audit log.

• Config schema
• Logs & observability docs

Edits to or deletions from sessions.db or the runtime trace are not detectable. A SHA-256 hash-chained audit file exists but records only certificate events, and tool receipts use ephemeral keys and are not persisted.

• Audit log source (hash chain)
• Config schema
• Tool receipts docs

Under the default supervised profile the agent's tools are confined to its workspace, outside the install `data/` directory that holds sessions and logs, so it cannot alter its record. Under `full` autonomy or `unrestricted_filesystem` that confinement is lifted and the record becomes writable.

• Autonomy levels docs
• Agent filesystem & identity docs

Runtime logs are JSONL and session history is SQLite, both readable with standard tools.

• Logs & observability docs
• Runtime state and persistence

In A2A calls the caller records the peer's task and context ids in its tool result, and the receiving ZeroClaw runs the turn under that context id. The receiving endpoint is stateless with no durable task store, so a matching record on its side is not guaranteed, and exchanges over chat channels have no shared record.

• A2A discovery docs
• A2A server source
• A2A client tool source

The runtime is open source under OSI-approved MIT OR Apache-2.0, and a Nix flake with a pinned Cargo.lock builds it. Bit-for-bit reproducible builds are not claimed or verified.

• LICENSE-MIT
• Nix flake

The daemon runs from the canonical `config.toml`; reload re-reads it, and env-var overrides are documented. The config is owner-readable, with secrets encrypted by a local key.

• Runtime state and persistence
• Config schema

Messages can be attributed only through the channel accounts and A2A bearer tokens the agent uses, whose credentials travel with the install, so recipients rely on each platform's authentication. Nothing the agent holds lets a recipient verify a message independently of those platforms.

• A2A discovery docs
• Secret store source

The action record (sessions.db and the runtime trace) carries no integrity data, so no tool can check it. The open `verify_chain` code validates only the certificate audit file.

• Audit log source (hash chain)
• Config schema

The owner can compare state between two points in time: the backup tool writes timestamped backups with per-file SHA-256 manifests (config, memory, audit and knowledge by default, configurable, optionally on a schedule), and the whole install is documented as open files and SQLite that can be copied and diffed.

• Backup tool source
• Config schema (backup)
• Runtime state and persistence

Personality/identity files and config are owner-editable, and runtime-injected prompt sections can be changed in the open source code.

• Agent filesystem & identity docs
• System prompt construction

Memory can be listed, read and cleared via `zeroclaw memory`, stored and deleted per key via the gateway API and dashboard, and edited directly in SQLite or markdown.

• Gateway routes (memory API)
• Agent filesystem & identity docs

Skills are editable files, SOPs are configurable, and the whole runtime is open source and modifiable.

• Skills docs
• Plugins docs

Owners can add custom MCP servers and WASM plugins, and scope tools via risk profiles (`auto_approve`, `always_ask`, `excluded_tools`, command allowlists).

• Autonomy levels docs
• Plugins docs

About 20 providers are supported, including local Ollama and any OpenAI-compatible endpoint, and tool-call parsing happens in the runtime.

• Ollama provider source
• Tool-call parser crate
• Philosophy: Provider-agnostic

No licensing, paid tiers or approvals exist. Plugin signature checking defaults to disabled and is owner-configurable.

• Plugin signature verification
• Philosophy: You own it

Channels enforce owner-set `allowed_users` lists, cross-channel sends through `send_via` can target only the originating chat or owner-configured peer groups, and HTTP, fetch and browser access is bounded by runtime domain allow and block lists.

• Config schema
• send_via tool source
• Autonomy levels docs

Supervised autonomy (the default) requires runtime-enforced approval for medium-risk actions; `always_ask`, OTP gating and fail-closed approval routing are also available.

• Autonomy levels docs
• Security model docs

`zeroclaw estop` halts in-flight tool calls at kill-all, network-kill, domain-block or tool-freeze levels, with optional OTP to resume.

• Emergency stop source
• Security model docs

No telemetry is sent; OpenTelemetry export is opt-in to an owner-set endpoint. The vendor runs no service that could collect or train on data.

• Philosophy: You own it
• Logs & observability docs

Secrets are stored in config.toml, encrypted with ChaCha20-Poly1305 under a local `.secret_key` (or in plaintext by choice), and can be inspected and revoked. Export lists the required secrets for re-entry.

• Secret store source
• Agent portability docs

All state lives in the local install directory and can be deleted after `install.sh --uninstall` or `zeroclaw service uninstall`. The vendor retains nothing; third-party model-provider retention is outside the runtime.

• Linux setup (uninstall)
• Runtime state and persistence