IronClaw vs ZeroClaw

IronClaw

Credentials stay in an encrypted store and are injected at the host boundary, and extensions declare per-tool permissions, network targets and OAuth scopes. The global auto-approve setting defaults to on in the 1.4.1 source, so tools marked ask, such as gmail.send_message, run unprompted until the owner turns it off.

ZeroClaw

Supervised autonomy is the default, so tools outside a short read-only list wait for the owner's approval, and secrets are encrypted in the config file. The docs state that command execution is not written to an audit log, and the project publishes no privacy policy or terms.

IronClaw

1. Open Settings and turn off global auto-approve, or set send and delete tools to ask each time, before connecting mail or chat accounts
2. Install with the release installer and run ironclaw onboard. 1.x does not migrate 0.29 data, so use a fresh home directory
3. Call POST /api/v1/responses with the bearer token from ~/.ironclaw/reborn/webui-token. Keep under 30 requests in 60 seconds
4. Resolve approval and OAuth gates in the web interface. The Responses API fails the turn instead of surfacing them
5. Connect MCP servers over HTTP only. The stdio transport is rejected

ZeroClaw

1. Keep [risk_profiles.<alias>] level = "supervised". full runs every tool not listed in always_ask, and the YOLO preset removes the sandbox and path rules too
2. Add sending and account tools such as send_via, google_workspace and http_request to always_ask so a session-level Always grant cannot skip the prompt
3. List senders in [peer_groups.<name>] external_peers. ["*"] accepts anyone on that channel
4. Set [web_fetch].allowed_domains and [http_request].allowed_domains. Fetches run unprompted and the OS sandbox does not block egress
5. Run one-shot tasks with zeroclaw agent -a <alias> -m "<task>". A cron or webhook turn has no prompt, so shell calls fall to the command policy