Nanobot separates channel installation from activation in a setup redesign

Nanobot is turning its expanding WebUI into an explicit setup surface rather than a collection of configuration fields. A channel redesign, still open at inspection, groups the catalog into two-column rows, uses compact setup dialogs and separates downloading dependencies from activating a channel. Installs would be serialized to avoid frontend races, while connection checks would describe whether a channel is usable rather than merely configured.

That proposal sits beside a merged September 10 settings change that exposes non-channel runtime options through an authenticated, validated mutation endpoint. Ordinary edits autosave, but listener changes and multiline editors require explicit saving. Saving configuration does not itself reload the agent or restart services. A separate provider-removal proposal checks for references before deleting configuration. Together these changes point toward an operator-facing distinction among installed software, saved state and a live integration.

The facts

- PR #5356 separates channel dependency installation from activation and serializes installation work. - The proposal includes browser-native WhatsApp QR linking with proxy configuration and streamlined Feishu and WeChat setup. - Its contributor reports 387 Python tests and 112 channel-focused Vitest tests, but explicitly did not pair a live WhatsApp phone. - Merged PR #5704 uses an explicit field allowlist and schema validation for authenticated runtime-setting mutations. - The settings change offers Restart or Restart later for pending runtime changes; saving alone does not restart a service. - PR #5352 proposes blocking provider removal when model presets or image generation still reference it, while retaining OAuth's existing sign-out flow.

Why it matters

An easy setup screen can hide a dangerous ambiguity: software can be present while a channel remains unusable, and saved settings can differ from the running process. Separating those states is more useful than claiming setup has become one click. The provider-removal work also recognizes that credentials and model choices form a dependency graph; deleting one row without checking its consumers can strand an otherwise healthy configuration.

Current

Inspected on 2026-09-11. The Nanobot release baseline is v0.3.0 published 2026-07-25T08:08:47Z. The main source was open (not merged) when captured. Release metadata bounds availability; proposals, merged mainline changes and packaged releases are not interchangeable.

Evidence

Primary evidence: HKUDS/nanobot PR #5356 (https://github.com/HKUDS/nanobot/pull/5356). Supporting context: HKUDS/nanobot PR #5352 (https://github.com/HKUDS/nanobot/pull/5352); HKUDS/nanobot PR #5704 (https://github.com/HKUDS/nanobot/pull/5704). These pages were inspected directly. Linked documentation establishes the product contract; it does not independently reproduce contributor or author experiments.

Operator take

Evaluate the redesign with a real channel lifecycle, not just a successful frontend build. Install, authenticate, activate, receive and reply should produce distinct observations, with an explicit restart boundary where required. Preserve the disclosure that WhatsApp's live phone leg was not exercised. For existing installations, the merged settings interface and the still-open setup/provider proposals must be treated as different availability states rather than one released bundle.

Caveat

The channel and provider-removal proposals were open; only the cited settings change was merged. Test counts are contributor-reported. Browser/gateway QR lifecycle tests do not establish live WhatsApp delivery, and external integrations were not reproduced here.