v0.5.0

Lightspeed v0.5.0 adds JavaScript code mode for composing session tools, queued-message steering, and a new environment protocol and lifecycle model. It also introduces session soft deletion and admin purge, tighter session configuration permissions, and improvements to workspace and setup interfaces.

Breaking changes and compatibility

• This is a greenfield release requiring a fresh database, not a supported in-place upgrade from v0.4.0. Runtime schema revision is 11. Migration 005 contains the new environment model, and migration 011 adds session soft deletion. There is no forward migration or automatic conversion from the v0.4.0 environment schema.
• A v0.4.0 database ledger records a different checksum for migration 005. The v0.5.0 runtime rejects that ledger. Do not point v0.5.0 at a v0.4.0 database or edit migration checksums to bypass the rejection. A higher schema revision does not make the databases compatible. Preserve old data with the old release; fresh installation does not carry over accounts, universes, sessions, credentials, files, environment records or workflow histories automatically.
• The former environment protocol 2 is replaced by two exact-match protocols: envd 4 (data and registration) and controller 4. Upgrade runtime, provider controllers and daemons together, including baked-in VM images. Release manifests replace environmentProtocolVersion with envdProtocolVersion and controllerProtocolVersion.
• Environment lifecycle now uses provisioning, open, closing, closed, and failed; display status is derived from lifecycle and provider observations. Incarnations and binding IDs/revisions are removed. Providers own power, idle, wake and ingress policy. Power and ingress API operations are synchronous pass-throughs; idle policy is a template default with an optional create-time override.
• deployment/environments/adopt and environments/idle-policy/put are removed. Update integrations for the regenerated API, CLI, registration receipts, provider bindings, cursor-based environment lists, and process/job/transfer contracts. Receipts no longer contain incarnationId. Environment transports are WebSocket or Unix socket; the old HTTP, stdio and SSH transports are removed. Protocol 4 also removes process notifications, fs/copy, fs/capture, fs/materialize, job artifacts, job/list, and process/resize.
• LIGHTSPEED_ENVIRONMENT_PUBLIC_URL is removed. A non-loopback environment gateway needs LIGHTSPEED_PUBLIC_BASE_URL or LIGHTSPEED_ENVIRONMENT_REGISTRATION_URLS for the signed registration origin. Run exactly one environment-gateway replica; API gateways can still scale. envd's default state directory moves to $XDG_STATE_HOME/lightspeed-envd, falling back to $HOME/.local/state/lightspeed-envd; review explicit LIGHTSPEED_ENVD_STATE_DIR settings and service permissions.
• Contributors can create sessions from existing profiles or universe defaults, but session configuration and per-message model/reasoning overrides require an Operator or Admin. Session close, delete and retention permissions are distinct. Review scoped service keys for the new session/delete and deployment/sessions method groups.
• Platform deletion and automatic retention now soft-delete closed sessions. Platform admins can separately purge retained history; there is no automatic purge or restore action. Direct session/delete and lightspeed session delete remain permanent by default; request softDelete or --soft-delete explicitly when retention is intended.
• The public API protocol identifier remains lightspeed.agent.api.v1. Platform schema revision remains 4 with baseline 0000_platform_baseline. These unchanged values do not promise compatibility with old environment contracts or workflow histories. Use matching clients and components from one release manifest.

Fresh installation and transition from v0.4.0

Use the self-hosting guide with a coherent v0.5.0 release manifest. There is no supported in-place database upgrade or data-preserving conversion from v0.4.0. If old data must remain accessible, retain the old installation and its recovery set separately; do not replace its database with the fresh one.

1. Before retiring an old installation, preserve its release, configuration, secrets and a coordinated backup of runtime and Platform databases, Temporal, object storage and relevant machine/connector state. Inventory provider targets and disks before losing access to their environment records. A fresh database does not delete external VMs, stop their processes, or adopt their targets.

2. Stop new work in the old installation and drain or cancel affected runs and jobs. Terminate remaining in-flight EnvironmentJobWorkflow executions through Temporal administration before retiring old workers: the history types changed and must not be replayed by v0.5.0 workers. Inspect parent sessions and machine processes separately; terminating a workflow does not undo effects or stop external processes. Preserve the old Temporal history for recovery, and use isolated, fresh Temporal state for v0.5.0 rather than attaching new workers to the old namespace.

3. Provision fresh runtime and Platform databases, separate object storage or an isolated prefix, and fresh Temporal state using the self-hosting configuration. Keep old databases and storage untouched. Set the new runtime's LIGHTSPEED_POSTGRES_URL to the fresh runtime database. With the v0.5.0 executable, run:

   lightspeed-runtime migrate
   lightspeed-runtime schema-version

   Require runtime schema revision 11 before starting services. Normal runtime startup verifies the ledger but does not migrate. Start Platform against its fresh database so it applies its own migrations. A checksum rejection means the database is not the expected fresh baseline; investigate the target rather than rewriting the ledger.

4. Start matching runtime, Platform, Configurator, connector and client components from one manifest. Configure the signed registration origin and exactly one environment-gateway replica. Deploy protocol-4 provider controllers and envd together, rebuild Incus templates with the matching daemon, and update integrations and receipt readers for the new contract. Passive Incus guests do not use outbound automatic upgrade. Outbound automatic upgrade requires a working deployment discovery document and archive URLs; publication alone does not install that route.

5. Set up accounts, universes, credentials, profiles, workspaces and optional connectors in the fresh installation. Register providers, enable universe bindings, create registration keys and environment credential bindings, and create new provisioned/external environments. Register daemons with the new secrets and review their state-directory settings explicitly. Configure session/profile attachments and registration-key allowlists with the new IDs. Old enrollment keys, environment IDs, job records and transfers are not automatically converted or resumed.

6. Verify sign-in, universe access, a new session, workspace file access and a small new environment job before opening ingress. Check provider create/close, registered reconnect and optional connectors. Reconcile previously performed external effects before resubmitting old work. If returning to v0.4.0, use the preserved old installation and its compatible recovery set; pointing the old executable at the fresh v0.5.0 database is not a rollback procedure.

See Upgrades and recovery for recovery planning, registered daemons for enrollment, and the environment protocol reference for provider integration.

Code mode and tool execution

• Enable Code mode in a profile or idle session to compose existing tools in one code_execute JavaScript call, including independent concurrent calls, MCP discovery, environment jobs, sub-agents and promise controls. Execution limits, cancellation and partial-outcome reports bound the work; completed effects are not rolled back and the whole script is not automatically retried.
• Shared content references and blob tools support reference-based file writes, environment file references and persisted web-fetch bodies. Code mode's text(), media() and file() helpers select output for the model. Session resources show when Code mode is enabled.
• Codex-style tool presentations prefer patch editing; OpenAI Responses supports grammar-constrained freeform patch calls and replay of existing calls. Anthropic tool schemas no longer use rejected top-level alternatives for blob/file writer inputs; runtime validation still enforces the allowed input combinations.

Sessions, workspaces and interface

• Queued messages can be promoted to steering with their text and attachments intact. If the target run has already finished, the UI sends an idempotent follow-up. Ambiguous steering outcomes retain a recoverable copy and require explicit recovery to avoid duplicates; conversion is not an atomic runtime operation.
• Queued follow-ups no longer starve Temporal timers while a run waits on an await. Conversation activity distinguishes tool waits from approval waits and avoids attributing another run's cancellation to current work.
• Workspace files gain drag-and-drop moves and Markdown preview controls. Setup pages use shared inventory tables and details dialogs for environments, MCP servers and models. The UI bundles IBM Plex Sans and Mono.

Environments and development

• Registration keys can be edited and rotated, environments can be updated, and closed rows are hidden by default. Provider credentials are optional. The Incus provider owns idle policy and wake-on-dial.
• envd supports Unix socket listeners, strict JSON-RPC handshakes, confined filesystem resolution, atomic conditional writes and rename. Process/job output uses byte offsets with explicit gaps and exit outcomes. Fixes address output loss, paging, resubmission, blocked input, and expensive output rewrites.
• Local development uses Chainguard MinIO server/client images and preserves access to existing root-owned MinIO volumes.

Validation limits

Fresh-install migration checks do not establish compatibility with a v0.4.0 database, historical sessions or Temporal histories. Real Incus idle/wake/power behavior still requires operator validation; PR #124 did not test against a real Incus server. This release supplies neither a v0.4.0 database conversion nor automatic conversion of old environment workflow histories or deployment orchestration.

Thanks to @cptspacemanspiff for the Unix listener and local MinIO changes in #118 and #117.

Full changelog: v0.4.0...v0.5.0