IronClaw vs LearnHarness

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.

LearnHarness

The in-app agent reads files but cannot change them or run commands, and a bundled skill gives other agents a documented read-only view of sessions and the knowledge graph. The project is 14 days old at 0.4.0, its file reads reach the whole home directory without approval, and it has no security policy.

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

LearnHarness

1. Use the bundled skill (skills/learnharness/SKILL.md) to read a learner's record. It needs Python 3.10 or later and writes nothing
2. Pass --format json before the subcommand, for example python3 -B scripts/graph.py --format json propositions
3. Treat stored answer keys and teacher prose as model-authored. A proposition in the graph is not evidence the learner understood it
4. Do not read auth.json, which sits one folder above the data folder and holds provider keys in plain text
5. Close the app or re-read when a stable snapshot matters. The readers do not lock files while the app writes