30 June 2026roder/v0.1.8

Runner lifecycle controls now reach app-server and SDK clients

Roder 0.1.8 completes the runner-lifecycle rollout by registering pause, resume, detach, and rejoin in the authoritative app-server method manifest, then regenerating the JSON schema and TypeScript and Python client types.

Roder running in Ghostty with runner lifecycle commands available through generated app-server clients — Ghostty capture of the Roder runner lifecycle CLI now backed by app-server schema plus generated TypeScript and Python client methods in 0.1.8.

What changed

Roder 0.1.8 makes the runner lifecycle API visible outside the terminal UI. The pause, resume, detach, and rejoin methods are now registered in the app-server manifest, and the generated schema plus TypeScript and Python client types include their request and result shapes.

The CLI commands introduced in 0.1.7 keep the same behavior. This release closes the gap between what the CLI can do and what other clients can discover through the supported app-server contract.

Why it matters

Desktop clients, IDE integrations, and automation can pause or rejoin a runner-bound thread without dropping to untyped JSON-RPC calls.
Schema-driven tooling no longer sees a narrower runner API than the runtime supports, which removes an integration trap where a lifecycle call worked in the CLI but was missing from generated clients or validation.
Blaxel setup stays the same. Existing BLAXEL_API_KEY or BL_API_KEY, BL_WORKSPACE, runner selection, and persisted thread state continue to work.
The release also refreshes validated Rust and SDK dependencies, keeping the published CLI and generated clients aligned on current supported libraries.

Using the lifecycle API

Use roder runners for the terminal workflow. Integrations that consume the app-server schema can now expose the same pause, resume, detach, and rejoin controls as typed client methods instead of hand-written protocol calls.