IronClaw Quick Start — Install & First Run (1.1.0)

Prerequisites

• A supported platform. 1.x publishes seven targets: macOS (Apple Silicon and Intel), Linux (x86_64 and aarch64, both gnu and static musl), and Windows (x86_64). Shell, PowerShell and MSI installers are provided.
• A model provider key for one of the 26 providers in the built-in catalog — NEAR AI, OpenAI, Anthropic, Gemini, Bedrock, Ollama, OpenRouter, Groq and DeepSeek among them, plus any OpenAI-compatible endpoint.
• A new data directory. Decide now where IRONCLAW_REBORN_HOME will point. It must not be an existing 0.29.x home.

Note the change from 0.29.x: there is no longer a Node.js version requirement, because the CLI ships as a compiled binary rather than an npm package. The ironclaw binary is the rearchitected CLI now; the old monolith builds as ironclaw-legacy and is not published at all.

Step 1 — Install the binary

Use the installer for your platform from the 1.1.0 release page — shell script, PowerShell script, or MSI on Windows. The old npm install -g ironclaw route no longer applies.

ironclaw --version

Confirm it reports a 1.1.x version before continuing. If you have a 0.29.x install on the same machine, check which binary is first on your PATH.

Step 2 — Point IRONCLAW_REBORN_HOME at a new directory

This is the step that protects your existing install. Set it before running onboarding:

export IRONCLAW_REBORN_HOME="$HOME/.ironclaw-v1"

Step 3 — Run guided onboarding

ironclaw onboard

ironclaw onboard provisions, in one pass:

• the config and the encrypted credential store — its master key goes into the OS keychain where one is available, falling back to a locally cached key file;
• an LLM provider, with interactive key entry and a live probe so a bad key fails during setup rather than on first use;
• a WebUI login token;
• and on macOS and Linux, the background service.

onboard --import-history parses its flag but does nothing as of the 1.x line — don't rely on it to bring anything across.

Step 4 — Start the web UI

ironclaw serve

This starts WebChat v2 with the frontend compiled into the binary — there is no separate asset deploy — serving chat, extensions, automations, settings and admin from root-level routes. 1.1.0 added route-level code splitting and pagination for sidebar thread lists.

On macOS and Linux you can instead manage it as a background service, installed by onboarding:

ironclaw service install
ironclaw service start
ironclaw service status

Runs as a launchd user agent on macOS and a systemd user unit on Linux. stop, restart and uninstall are also available.

Step 5 — Manage models and providers

ironclaw models

The built-in catalog carries 26 providers. Any OpenAI-compatible endpoint works even if it isn't in the catalog, so local inference through Ollama and hosted aggregators like OpenRouter are both first-class.

Step 6 — Add extensions

1.x ships 12 first-party extensions embedded in the binary, so they install with no network fetch: GitHub, Gmail, Google Calendar, Docs, Drive, Sheets, Slides, Notion, NEAR AI MCP, Slack, Telegram and web access.

1.1.0 adds three things worth knowing about on a fresh install:

• Custom hosted MCP servers, registered from the WebUI.
• IronHub deep-link installs, including private manifest sources.
• Native /ironclaw Slack slash commands, plus durable cross-channel attachments.

Memory is now modeled as a userland extension with declared capabilities rather than a built-in.

What isn't there yet

A 1.x version number does not mean feature parity with 0.29.x, and the release notes are candid about it. As of the 1.0.0 rearchitecture these CLI surfaces either return "not implemented yet" or have no equivalent:

If your 0.29.x setup leans on MCP or memory from the CLI, 1.x is not yet where you land. New IronClaw users should start on 1.1.0; existing 0.29.x users should evaluate in parallel and keep 0.29.1 running.

Storage

File-backed libSQL by default, with PostgreSQL available by config. 1.1.0 normalizes extension persistence into typed installation, user-membership and credential-binding records.

One quality-of-life change worth calling out: in 1.1.0 every model termination path — no progress, iteration limit, disabled capability, denied call, provider error — now tells the model what would unlock the call, instead of stopping opaquely. Failures are much easier to diagnose than they were at 1.0.0.

Upgrading between 1.x releases

From 1.0.0 to 1.1.0: no migration steps. The startup migration preserves 1.0.0 state — existing workspace, extension and Railway artifacts stay intact — and the hosted MCP egress target is preserved for registered MCP servers. The one behavioral removal is the Slack alias above.

Looking ahead to 1.1.1: an urgent patch candidate, 1.1.1-rc.1, landed four days after 1.1.0 went stable. It is a prerelease — 1.1.0 remains current stable — but if you are planning an upgrade path, note that going 1.1.0 → 1.1.1 needs no offline data transform (stop writers, snapshot the database/volume, start against the same durable state), whereas going 0.29.x-era 1.0.0 → 1.1.1 requires a database-native snapshot first, and Slack/Telegram state is skipped by default and must be reconfigured.

Where to go next

• The 1.0.0 rearchitecture writeup — what was rebuilt and why.
• 1.1.0 stable and 1.1.1-rc.1 — the current release picture.
• IronClaw vs OpenClaw — which one fits your threat model.
• Cross-platform security center — hardening that applies whichever agent you run.