Documentation

What SenClaw is, what it publishes, and what it does and does not promise.

Find a package, install it, and publish your first one.

The install paths, what each one verifies, and where files land.

How to publish, what a version means, and what you can change afterwards.

What to upload for each kind, what its manifest block carries, and the exact web and API calls that publish it.

A Space App from zero: its own repo on app-space-sdk, a loopback server with an embedded UI and MCP, packed into an installable zip.

Everything the daemon offers an app: bridge actions, REST endpoints, MCP in both directions, the iframe bridge, and chat widgets.

One daemon contract, four SDKs — Rust, Node, Python and Go: what each covers, what every app shares, and how to choose.

Build a Space App in TypeScript with @senclaw/space-sdk: the daemon client, the lifecycle helpers, an MCP server in a few lines, and dispatch.

Build a Space App in Python with senclaw-space-sdk: standard library only, one serve() call for health, UI, REST and MCP, and a venv the daemon manages.

Build a Space App in Go: standard library only, one Serve() call for health, UI, REST and MCP — and the missing install step that catches every Go app once.

Registry metadata, the first publish, shipping updates, and how installed apps know a new version exists.

Cards inline in the chat box and on the dashboard: choosing between built-in kinds, app and plugin widgets — and the manifest entry, HTML page, text fallback and skill that make one work.

Give a tool a new name, or override it with another implementation — no code edits, no daemon restart: the alias registry, the resolve path, the REST API, and the manifest declaration with its approval gate.

SenClaw's two automation systems — scheduled tasks that reply in a chat, and background tasks that run unattended into run records — plus calendar reminders: creating, managing, lifecycle, safety limits and the REST APIs.

A work board where agents pick up and run the cards in the Ready column: boards, columns and cards, the dispatcher cycle and its outcomes, AI board generation, column templates, the MCP toolset and the REST API.

Run models from OAuth subscription accounts (Claude Code, Codex, Copilot, Gemini CLI…) or free-tier endpoints: the two sign-in flows, remote use, token refresh and storage, binding accounts to models, and troubleshooting.

Run shell commands and code isolated from the real machine: what your platform can enforce, the enforcement switches, disk read modes, port rules, restricting egress to one site, activity tracing and the sbx_ toolset.

Confine an installed app to its own directories and a named set of sites: the three switches, how domain allowlisting is enforced by a proxy, what each platform can actually enforce, measured before/after results, and the traps that break real apps.

Is it running, since when, how many restarts, what is it talking to, and is it really sandboxed — the runtime panel, the fleet view, the crash-loop and adopted-process signals, and the runtime API.

How the isolation is actually built: the two backends, the generated Seatbelt profile, the three design decisions, port enforcement, tracing, and the measured findings — including a loopback escape that was found against a live daemon and fixed.

Opening the daemon beyond loopback: the bind-host opt-in, the API token it turns on, how each client sends it, and the limits of the scheme.

Every field a package manifest can carry, per kind.

What a package declares it will touch, and what happens when that widens.

The four package kinds, where each installs, and the platform ids apps are published against.

Every endpoint SenClaw serves, what authenticates it, and what it returns.

What the registry actually enforces, and where the limits are.

How to report a package, what happens next, and what moderators can do.