ZeroClaw turns channel instances into first-class plugin objects

zeroclaw-labs/zeroclaw PR #10146 is the inspected primary source: “feat(plugins): activate logical channel instances.” The related records below were inspected as supporting context rather than independent confirmation.

The facts

- zeroclaw-labs/zeroclaw PR #10146 was created 2026-08-19T21:05:11Z and was open at inspection; its title is “feat(plugins): activate logical channel instances.” - zeroclaw-labs/zeroclaw issue #10147 was created 2026-08-19T21:50:18Z and was open at inspection; its title is “[Bug]: Explicit config init sections cannot be completed across CLI processes.” - zeroclaw-labs/zeroclaw PR #10142 was created 2026-08-19T19:09:38Z and was open at inspection; its title is “feat(relay): secure transport and browser enrollment frontdoor (supersedes #9080).” - The repository reported 32619 stars, 763 open issues, default branch master, and last push 2026-08-20T01:11:11Z. - The latest tagged-release baseline checked was v0.8.4 published 2026-08-02T21:00:00Z.

What changed

zeroclaw-labs/zeroclaw PR #10146 reports: Summary **Base branch:** master (all contributions). **Depends on #9126** — the branch carries #9126's head until it merges; the isolated delta is five commits, 14 files, +1,726/−88. **What changed and why:** This is the re-cut of #8852's activation slice onto an accepted base, following the shape that landed #9137. It is the PR that makes the daemon construct channel plugins at all: today WasmChannel::from_wasm has no production caller (it appears only in crates/zeroclaw-plugins/tests/channel_plugin_e2e.rs), so no channel plugin can run. After this, a [channels.plugin. ] declaration resolves to a real component through the existing supervised-listener lifecycle. **Config surface:** [channels.plugin. ] → PluginChannelConfig { package, enabled }, registered in channel_info(), has_any_enabled(), channel_presence(), and V3_CHANNEL_TYPES; alias validated by the shared alias grammar, package by the shared slug grammar now in zeroclaw-api::plugin. plugins.max_plugins becomes plugins.max_active_instances. **Guest-free activation plan:** PluginActivationPlan::build decides which logical instances (channel, tool, skill) activate under one shared max_active_instances ceiling without ever touching component bytes — a test proves it with an invalid wasm payload. Explicit channel candidates require an enabled declaration, an enabled owning agent, and an installed package that declares the channel capability. **Daemon boot hook:** start_channels and doctor_channels append activated plugin channels into the configured-channel set, so they receive the existing supervision, backoff, and composite-key registry rather than a parallel lifecycle. The loader constructs each through WasmChannel::from_wasm with the

zeroclaw-labs/zeroclaw issue #10147 reports: Affected component config/onboarding Severity S2 — degraded behavior Current behavior Explicitly initializing an optional config section whose nested type has required leaves can persist a partial section that cannot be completed by a later CLI process. For example, config init gateway.tls materializes and saves [gateway.tls] without the required cert_path and key_path. On the next command, resilient loading drops the malformed gateway parent. config set gateway.tls.cert_path... then cannot descend through the resulting None, so the operator cannot finish the section across ordinary CLI invocations. The same ownership gap applies to the currently known required-field optional sections: gateway.tls transcription.local_whisper tunnel.openvpn PR #9454 deliberately fixes only bare/ancestor-scoped config init so a fresh full config strictly reloads. It accurately discloses this explicit-init limitation but does not change it. Expected behavior An explicitly targeted required-field section should have one supported, round-trippable CLI path. Acceptable designs include collecting the required leaves before persisting, refusing the partial init with actionable guidance, or teaching the canonical config mutation path to materialize the missing optional parents safely. The solution should preserve zeroclaw_config::schema::Config as the source of truth and must survive save plus a new-process reload. Steps to reproduce The second process reports the malformed parent/reset behavior, and the setters cannot vivify the absent optional section into a valid persisted value. Acceptance criteria A production-boundary regression starts from an

zeroclaw-labs/zeroclaw PR #10142 reports: Summary **Base branch:** master **What changed and why:** Carries @Nillth's ZeroRelay secure-transport work forward. It makes the remote WSS plane mandatory mutual TLS with a per-daemon CA and CSR-only issuance; adds zerorelay, a blind forwarder that pairs a daemon connection with a client connection without terminating the inner TLS session, so a daemon behind NAT/CGNAT is reachable without the relay holding keys or seeing plaintext; adds over-the-wire enrollment gated on a pairing code and confirmed by a short-auth-string; and adds an opt-in browser frontdoor. The branch is merged up to current master and the three CI failures on #9080 are fixed. **Scope boundary:** No OIDC or external identity. Enrollment is pairing-code + CSR + SAS only; RFC #7141 would later attach at the POST /enroll boundary this PR creates. No CA rotation orchestration. No QUIC or parallel-link relay transport. **Blast radius:** zerocode's connection path, the daemon WSS listener, the gateway dashboard when reached through the relay, and the release matrix (new zerorelay binary). **Linked issue(s):** Supersedes #9080. Related #8358. **Labels:** enhancement, ci, docs, dependencies, core, config, daemon, gateway, runtime, security, scripts, domain:security, domain:architecture, web, zerocode, risk:high, size:XL Testing (required) How you can test (when useful) **Reviewer testing requested?** Yes **Interface(s) exercised:** cli (zerocode), web (relay frontdoor and dashboard) **Setup / preconditions:** Linux host with a Chrome or Chromium binary and

Why it matters

Named channel instances are the point where credentials, routing and lifecycle ownership meet. If configuration cannot survive process boundaries, the plugin abstraction is cosmetic. The operator test is whether the system remains bounded and its receipts still describe the action after failure, retry or restart.

Current

The primary record was open when captured on 2026-08-20. The tagged-release baseline was v0.8.4 published 2026-08-02T21:00:00Z. Repository metadata, full source bodies, current pull requests and issues, releases, Google News, Hacker News, Lobsters, Metamesh and the rendered ClawCharts row were inspected. ClawCharts selected the subject; it did not prove the claim.

Evidence

The primary URL is https://github.com/zeroclaw-labs/zeroclaw/pull/10146. Supporting records are https://github.com/zeroclaw-labs/zeroclaw/issues/10147 and https://github.com/zeroclaw-labs/zeroclaw/pull/10142. Source bodies, timestamps and states are preserved in the daily evidence bundle. Test counts and reproductions remain attributed to their authors unless identified as independently rerun.

Source boundary

Open work is described as open, closed work as closed, and operator reports as reports. A pull request is evidence of proposed or reviewed direction, not proof of a shipped release. Search residue, package mirrors and historically published source spines were excluded.

Operator take

Give each channel instance durable identity and capability-scoped configuration, then prove enrollment and restart preserve the same owner and transport policy. Preserve a before-state receipt, make the smallest reversible change, and verify the original failure independently.

Caveat

Public project records are mutable. Status, scope and evidence can change after publication. This brief records the inspected state and does not authorize changes to a reader’s deployment.

Source inspected; source state, environment and release boundary remain explicit.