nearai/ironclaw

IronClaw is a self-hosted personal AI assistant, written in Rust, that combines a chat agent, background routines, and an extensible tool system while keeping data and credentials on your own machine. It suits people who want an always-on assistant with stronger isolation and credential handling than a typical hosted chat client, and who are willing to run and configure a local service.

What it does and how it works

You talk to the assistant through a terminal REPL, a browser WebUI, HTTP webhooks, or messaging channels such as Telegram and Slack. Behind the chat sits an agent loop that routes requests, runs jobs in parallel, and can execute scheduled or event-triggered routines in the background. Memory combines full-text and vector search over a workspace filesystem, plus identity files that keep preferences consistent across sessions.

The distinguishing mechanism is the tool sandbox. Untrusted tools run as WebAssembly modules with explicit, capability-based permissions for HTTP, secrets, and tool invocation; network access is limited to an approved host/path list. Credentials are injected at the host boundary rather than handed to the tool, and requests and responses are scanned for secret leaks. Incoming external content is also screened for prompt-injection patterns, with policy levels from warn to block. The README also describes dynamic tool building, where you describe a capability you need and IronClaw builds it as a WASM tool, plus MCP server connections and drop-in plugins (project README).

Getting started and requirements

The primary path is the guided ironclaw onboard flow: it asks you to pick an LLM provider, stores the API key in an encrypted local store, writes configuration under your home directory, and on macOS or Linux installs and starts a background service and prints a WebUI login link (installation instructions). Prebuilt installers cover macOS, Linux, and Windows/WSL, with a Windows MSI and PowerShell script as alternatives. Building from source instead requires Rust 1.96+ and Node.js 22+ with Corepack/pnpm. On Windows, the README directs users to start the WebUI in the foreground rather than rely on the background service.

Configuration changes do not restart the running service automatically, so a change that affects the service needs an explicit restart command. Secrets are always entered through a hidden prompt, never as a command argument. Slack and Telegram channels are enabled through the WebUI Extensions page after installing the extension, not through config keys, which differs from most other settings.

Security scope and open questions

The README frames the security design around layered defenses: WASM isolation, endpoint allowlisting, credential injection and leak scanning, prompt-injection policy, local encrypted storage, and a full audit log of tool executions. These are the author's design claims; the supplied material contains no independent security audit or evaluation of whether the sandbox contains particular attack classes. A Hacker News commenter in the launch thread argued that the design did not clearly state its threat model and what is sandboxed from what (HN comment), while other commenters defended the value of granular isolation for untrusted skills (HN reply). One reply also raised the question of an agent writing its own tools (HN reply). Treat the isolation story as a design direction to verify for your own threat model, not as a proven guarantee.

The project is licensed under Apache-2.0 or MIT, at your option (repository). It is a Rust reimplementation inspired by OpenClaw, with a feature-parity tracker maintained separately (feature parity).