Tsuno

角

Beyond the old outline.

Horns emerge at dawn,
each new growth reaches outward,
past the old outline. 角

The workshop opened with Bungei Fukkō. Now the work reaches beyond its doors.

LunarWing v2.1.6.0, Tsuno (角), is released. Its name means horns: growth made visible, branching from a foundation strong enough to support it. The earlier chapters gave LunarWing its shape. This one begins to change that shape, connecting capabilities that once stood apart and extending what external agents can accomplish.

This is a substantial release for external workers, scheduled work, orchestration, and the systems that keep them reliable.

Highlights

External workers reach into LunarWing

External workers can now invoke a carefully selected set of host tools through a hub-mediated tool proxy. Workspace memory, coordination knowledge, and GitLab capabilities become accessible without handing a worker unrestricted control over the host.

Kimi Code and Pebble use an MCP bridge; OpenCode and OpenCode 2 expose the same initial capabilities through worker-side plugins. Tool calls return through the hub, which remains responsible for enforcing grants and rejecting forbidden operations. Access is disabled by default until an operator explicitly grants it.

The significance is not simply that workers have more tools. They can now participate in more of LunarWing’s existing world while remaining accountable to the system that owns those capabilities.

Work that continues on a schedule

Cron missions now run on external workers. A supervisor manages scheduled ticks, liveness, cancellation, retries, persisted pause state, and circuit breakers. Each mission receives its own confined project directory and its own tool permissions, distinct from those of interactive jobs.

Cron activity also has bounded retention and clearer visibility: routine job listings no longer need to be crowded out by thousands of scheduled ticks. Busy workers are accounted for explicitly, rather than leaving operators to infer what happened.

Where workers previously waited for a task, they can now become part of an ongoing rhythm of work.

More ways to guide and operate workers

OpenCode gains a control channel for acknowledged follow-up prompts during a running task, including a defined final wrap-up turn. Kimi Code gains a dedicated task-runner process. Worker image rollouts now account for image identity, helping updated images reach running tenants through the normal restart process.

The released upstream pins are Kimi Code 2.3.0, OpenCode v1.18.25, and OpenCode 2 v2.1.2. Later upstream releases are not included in this tag. Pebble keeps its existing upstream source revision, with refreshed security dependencies.

Reproducible OpenCode model-catalog inputs, OpenCode 2 SDK compatibility checks, toolchain build gates, and worker-exposure controls reinforce the new operational surface.

A stronger foundation for the wider system

Expansion depends on clear boundaries. Tsuno also brings substantial security and reliability work: credential redaction across HTTP and proxy responses, tighter separation between worker tasks and bridge credentials, safer tenant-owned workspace handling, hardened mission webhooks, and OpenRC proxy changes that prevent tenant-controlled URLs from being evaluated as root.

Mission interruption records, outcome notices, approval gates, and cron control state receive more durable and truthful accounting. A broad dependency refresh includes Wasmtime/WASI 36.0.19, rustls 0.23.46, webpki root-store fixes, and additional October security updates.

The security audit also documents fourteen accepted advisory IDs, rather than presenting the dependency graph as risk-free. Legacy libSQL remote-replica dependencies are kept behind an explicit, non-default feature.

Upgrading

This release has several changes operators should review before deployment.

OpenRC multi-tenant hosts require a proxy migration. In a maintenance window, pause the health cron and watchdog, render the patched proxy units with sudo ic/scripts/lunarwing-mt-admin.sh render-units --all-proxies, update each proxy tenant’s lunarwing-proxy.py, and follow the documented restart and health-pipeline steps. Do not restart tenants against their old proxy script.
Turso/libSQL remote-replica sync is now opt-in at build time. Builds using LIBSQL_URL need --features libsql-remote-replica. Default builds fail closed rather than silently switching a replica to a standalone database. The feature retains documented legacy dependency exposure.
Cron tick history can be deleted on first startup. The new default retention window keeps the latest 50 job rows per mission, plus its protected anchor. Back up the database or increase cron.retain_last_ticks before the first supervisor start if older tick events and usage records matter.
Rebuild and promote all four worker images, restart tenants, and rebuild and restart the daemon and XMPP bridge to deploy the binary security fixes. Rebuild affected WASM channels and tools as part of the release upgrade.

There are no new SQL migrations; V28 remains current, and the multi-tenant port registry remains at v17. Full upgrade instructions and compatibility details are in the v2.1.6.0 release notes.

The shape of what comes next

Tsuno does not abandon the care that defined the earlier releases. The worker proxy still has a deliberately narrow capability set. External workers do not automatically inherit core MCP configuration. The onboarding console remains a trusted local interface, and other documented deployment constraints continue to apply.

But the direction has changed. The boundaries built in earlier chapters are no longer just places where LunarWing stops. They are foundations from which new capabilities can grow.

Not another wall,
new horns reach beyond the old,
the world grows wider. 角

LunarWing v2.1.6.0: Tsuno release
Source repository