ZeroClaw

Export is immediate and needs no approval: the ops docs say a tar of ~/.zeroclaw covers everything. There is no export/import or restore command (the only `migrate` imports from OpenClaw) and no documented restore procedure, so restoring means installing the binary and unpacking the archive by hand (one shortfall).

• Runtime state and persistence (backup section)
• Ops overview: backups
• CLI command definitions
• Agent backup tool (workspace-local)

Every class of state sits under the install root: config and encrypted secrets with the owner's key file, sessions, memory (SQLite with source text; embeddings off by default), cron jobs, SOP runs, skills, per-agent workspaces and identity files. OAuth logins use the model vendors' own public clients, not a ZeroClaw-registered broker, so integrations re-link without the project. There is no manifest.

• State map
• Agent filesystem components
• Secret key storage
• Embedding provider default `none`
• OpenAI OAuth public client
• Copilot client

The runtime is MIT OR Apache-2.0 and needs no key, account or activation. Every contact with a project endpoint is optional and owner-triggered: `zeroclaw update` (GitHub Releases), the plugin registry (overridable by env var), the skills registry (overridable URL), and locale fetch. The relay is self-hosted and off by default. Desk review only; the provider-blocked run is hands-on.

• Licence
• Update command
• Ops overview: no auto-update
• Plugin registry URL override
• Skills registry
• Relay config default (disabled)

Ollama is a first-party keyless provider. Models without native tool calling get tools through the runtime's text-based PromptGuided fallback, and embeddings, transcription (local Whisper) and web search all have non-vendor options. No approval is needed to switch models. No formal minimum-model contract is published. Desk review only; the model swap is hands-on.

• Provider catalog
• Ollama capabilities
• Prompt-guided tool calling fallback
• Multi-model setup
• Local Whisper transcription

The default install is local-first: all agent state is always in ~/.zeroclaw on the owner's machine. ZeroClaw Labs holds no account or copy, so termination or shutdown cannot remove access.

• State map
• Quickstart

State is stored as TOML config, SQLite databases (memory, sessions, cron, control plane), JSONL logs and plain workspace/skill files. SQLite embeds its own schema and the DDL is in public source. Secrets use ChaCha20-Poly1305 with an owner-held local key. The docs book lists paths but not table schemas or the `enc2:` layout; those are documented only in open source.

• State map
• Memory SQLite schema
• Secret encryption format
• Log JSONL schema

`log_llm_request_payload = "full"` records the full provider-bound message list for main-loop calls, and `zeroclaw config list` shows effective values including env overrides. However, auxiliary model calls (memory consolidation, on by default via auto_save, and the channel reply-intent classifier) are not captured. Tool instructions appended in the provider layer for non-native-tool models are added after the capture point. These are visible only in source (one shortfall).

• Observability: request payload logging
• Capture point
• Provider-layer tool instruction injection
• Consolidation prompt
• Channel classifier
• config list env-override legend

The source has no telemetry, analytics or crash reporting, and no endpoint on a project domain; OTel export has no endpoint by default. ZeroClaw Labs operates no service that receives owner data in the default configuration.

• OTel defaults
• Update check (GitHub API)
• Dashboard version check

Quickstart's provider picker preselects its first entry, OpenRouter, from a hand-ordered list, and no reason or commercial relationship is disclosed. The default is replaceable, with about 40 providers. There are no sponsored tools or paid placement in prompts, but no binding no-steering commitment exists, so the pass is withheld (G12).

• Provider ordering
• Quickstart picker `.default(0)`
• Quickstart state

Tool calls are logged to data/state/runtime-trace.jsonl, but persistence defaults to Rolling with max_entries = 200, and cron run history is pruned to 50. When the queue is full, events are dropped with only a tracing warning (the log is documented as best-effort). The recording floor is `warn` for interactive `zeroclaw agent` and ACP sessions, so INFO tool-call events on those paths are not persisted. That is three shortfalls.

• Log persistence defaults
• Observability docs
• Dropped events
• Logging: best-effort
• Per-command log floor
• Tool call logging
• Cron run history

The action record (runtime-trace.jsonl) is plain JSONL with no hash chain or signature. The Merkle-chained audit.log covers only certificate events and has a constant genesis hash. Tool receipts use an ephemeral in-memory HMAC key and cannot be verified by a third party.

• Trace log format
• Audit log (cert events)
• Audit logger wiring
• Tool receipts

The record sits outside the agent workspace, and the default policy (workspace_only, forbidden_paths) blocks file tools from it. But in the recommended Balanced preset (allowed_commands = ["*"]), the prebuilt binary falls back to a no-op sandbox when no backend is available. A script run through the shell can then reach the file, so protection rests on policy with one bypass path.

• Log path initialisation
• Default forbidden paths
• Balanced preset
• Sandbox fallback to no-op
• Cargo features

All components, including the dashboard and relay, are MIT OR Apache-2.0 in the repository. The v0.8.5 release ships Sigstore-signed SLSA v1 provenance bundles binding each artifact's SHA-256 (for example the default x86_64 Linux tarball) to commit cb2b20a, and documents how to verify them. install.sh itself checks only SHA256SUMS. Desk review only; build verification is hands-on.

• Licence
• Release artifact verification
• Release workflow attest step
• install.sh checksum check
• v0.8.5 release (verification bundle)

The project issues no identity. The daemon mints its own local CA, the optional relay uses a locally held Ed25519 key, and an A2A card can be served under an owner URL but is unsigned and off by default. Outbound actions are not signed, so attribution is per channel only (one gap).

• Local cert generation
• Relay protocol
• A2A discovery

An opt-in memory audit records memory operations (operation, key, namespace, session), but not content, before/after values or actor type, and there is no restore. Config has no change history: the .bak is removed after a successful write, and the docs point to manual backup restore. Instructions and skills are not versioned.

• Config lifecycle: no rollback
• Memory audit config
• Memory audit records

Owner-layer files (AGENTS.md, SOUL.md, IDENTITY.md, etc.) and skills are editable files. Large parts of the base system prompt (tool honesty, safety, channel capabilities, calibration note) and the memory-consolidation prompt are hard-coded, and config cannot replace them.

• System prompt bootstrap files
• Hard-coded safety section
• Calibration note
• Consolidation prompt
• Skills

The main memory store can be listed, read, upserted and deleted item by item from the CLI and dashboard. Session history, which the agent reuses, can be listed but only deleted or renamed as whole sessions; individual messages cannot be edited or deleted (one store not fully editable). The optional relationship-memory graph has no owner edit surface.

• memory CLI
• Gateway memory API
• SQLite upsert
• Relationship memory

Owners can add any MCP server, or define shell/http/script tools in skills, without review. Any built-in can be removed with the risk profile's excluded_tools/allowed_tools, applied to all paths in one filter.

• Tools overview
• Tool policy filter
• Skill tools

Autonomy, workspace scoping, forbidden paths, the command guard, the sandbox, rate limits and leak detection can all be switched off in config. The path guards (`..`, encoded traversal, `~user`) and untrusted-content framing have no off switch.

• YOLO mode
• Path guard
• External content framing
• Security model

There is no auto-update or remote flag. `zeroclaw update` runs only when the owner starts it, can pin `--version`, and the dashboard upgrade is owner-triggered with release notes. The model is an owner-set string. The opt-in open_skills sync (off by default) pulls a third-party repo weekly.

• Update command
• Dashboard version/upgrade
• open_skills default

There are per-sender peer groups, per-domain allow/deny for HTTP/fetch/browser, a command allowlist, path rules and per-tool allow/exclude lists; file tools refuse to write config.toml. The product has no payment capability, so spend was treated as met under G11. Cron `delivery.to` accepts any recipient without checking peer groups (one bypass path). The default-registered model_routing_config tool can also rewrite the calling agent's own risk profile and tool list, held back only by the generic supervised approval prompt.

• Peer groups
• Sandboxing and scope
• file_write config protection
• model_routing_config self-upsert
• Cron delivery

The owner can gate any tool with always_ask, and the runtime overwrites any model-supplied `approved` flag; channels and cron fail closed. However, bounded delegate sub-loops are built with `approval: None`, so their tool calls bypass the gate (one path).

• Autonomy levels
• Approval manager
• Approval gate
• Bounded delegate approval: None
• Default auto_approve

The docs describe `zeroclaw estop` as halting all in-flight tool calls, but it is disabled by default. The code only writes a state file that no runtime component reads. The working stop is ending the daemon (`zeroclaw service stop` / SIGTERM). Separate CLI/agent processes need their own steps, and the enabled service plus persisted cron jobs resume at next login. There is no documented within-seconds guarantee.

• Security model: estop
• estop command
• estop defaults
• Estop manager
• Service docs

There is no telemetry or analytics, update checks are manual, and model content goes only to the owner-selected provider. However, web_search is enabled by default with DuckDuckGo and auto-approved, so model-written queries go to a third party the owner did not specifically choose (it can be turned off). OpenRouter requests carry fixed, undocumented app-attribution headers. The docs' "no telemetry" statements are not binding terms, and no privacy policy exists.

• Web search default enabled
• Default search provider
• OpenRouter attribution headers
• Philosophy: you own it
• ZeroClaw website

Secrets are encrypted locally with an owner-held key and the project holds no copy. Credentials can be listed and revoked one by one across `config list --secrets`, `auth list/logout` and paired-device tokens. Revocation through CLI config writes takes effect only on the next load or reload of the running daemon.

• auth CLI
• config list secrets
• Config lifecycle: reload
• State map: auth profiles

`install.sh --uninstall` removes the service and binary and, after an interactive prompt, deletes ~/.zeroclaw. The piped default install path keeps data non-interactively, other platforms need a manual rm, and no completion limit is stated. There are no project-side copies.

• install.sh uninstall
• Linux uninstall docs
• Windows uninstall docs