Local Solana runtime

A local Solana runtime with real guard rails.

TrenchClaw is a Bun + TypeScript runtime for Solana operator workflows with validated actions, managed wallets, local state, and a GUI that talks to the runtime instead of replacing it.

The important difference from thinner OpenClaw-style wrappers is the execution model: tool-gated execution, settings-aware policy checks, instance-scoped state under `.runtime-state`, and a repo-tracked `.runtime` contract that is not treated as live mutable state.

Open docs Read architecture View repository

Bun + TS

Compiled runtime, typed actions, local services, and a local web app

Instance-scoped

Vaults, wallets, logs, settings, and workspace state stay grouped per instance

Policy-backed

Tool exposure, dangerous actions, and write scope are constrained by runtime rules

$ trenchclaw

booting runtime...

readonly app loaded from ~/.local/share/trenchclaw/current

state root: ~/.trenchclaw

scheduler online

web gui: http://127.0.0.1:4173

docs: /docs/getting-started

ready for actions and routines

Install Release installer

macOS

copy + run

curl --proto '=https' --tlsv1.2 -sSfL https://trenchclaw.vercel.app/install/macos-bootstrap.sh | bash

Linux

copy + run

curl --proto '=https' --tlsv1.2 -sSfL https://trenchclaw.vercel.app/install/linux-bootstrap.sh | bash

Fetches the installer, which resolves a GitHub Release tarball and verifies its checksum before install.

Start here

The three pages that explain the product.

Start with setup, move to keys only when you need to change providers, and use architecture when you want the runtime model instead of the onboarding path.

Guide

Getting Started

Install TrenchClaw, launch the runtime, sign into an instance, add one AI key, and get to a clean first chat.

Guide

Keys and Settings

Which keys matter, which settings matter, and how to keep the default TrenchClaw setup clean.

Reference

Architecture

How TrenchClaw actually ships: runtime authority, tool snapshots, lane routing, instance state, and execution boundaries.

Guard rails

Why TrenchClaw is not just a wrapper.

The runtime decides what exists, what is enabled, and where state is allowed to live. That makes the operator surface narrower, more inspectable, and easier to reason about than broad shell-first agent setups.

Tool-gated execution

The model only gets the action and workspace tools that are present in the runtime tool snapshot for the current run.

Policy checks before side effects

Unsupported or disabled actions are blocked before execution, and dangerous actions can require explicit user confirmation.

Instance-scoped state

Vaults, wallets, settings, logs, caches, and workspace files live under one active instance instead of a loose shared folder.

Runtime-owned source of truth

The GUI is a client for runtime APIs. The canonical state lives in the runtime layer and on disk, not in frontend-only state.

Stack

What actually ships.

Runtime

Bun + TypeScript core runtime with action dispatch, policy evaluation, and local service boot.

Frontend

SvelteKit local GUI that talks to runtime transport APIs instead of owning durable state.

Solana

@solana/kit plus provider-agnostic RPC wiring, wallet management, and Jupiter Ultra integration surfaces.

State

SQLite, JSONL logs, wallet sidecars, and instance-scoped filesystem storage under the runtime state root.

Runtime state model

The folders that matter.

Boundary	What it is	Why it matters
.runtime	Repo-tracked runtime contract and template area	Not the live mutable state root
.runtime-state	Per-instance mutable state for settings, vaults, wallets, logs, and SQLite	This is the source of truth at runtime
Workspace	Instance-scoped operator files, notes, configs, routines, and output	Keeps automation and manual work attached to one instance

Local GUI

The GUI sits on top of the runtime.

The frontend is there to inspect and operate the runtime cleanly. The runtime remains the storage and execution authority underneath it.