NanoClaw drafts browser-managed setup that can outlive the terminal

NanoClaw is proposing a setup flow in which a browser account portal and a persistent host connection coordinate optional integrations. The September 6 draft, updated in the current scan, moves Echo and Slack setup into a WorkOS-backed browser flow while the originating installation continues locally. Its practical ambition is delayed approval without asking the owner to reopen a terminal; human review and real-workspace acceptance are still pending.

The facts

- The draft keeps an authenticated account-cell WebSocket open from the running service after the foreground setup process exits. - The service reuses its saved installation identity, renews tickets and reconnects after network or cell loss rather than enrolling another device. - The saved initial Slack-install worker can resume after delayed approval and a virtual-machine restart, according to the proposal's acceptance notes. - Initial installation watches for workspace approval for seven days, while additional agents wait five minutes and then park for a later explicit continuation. - Credentials remain outside the browser and account cell; cell notifications wake locally saved authorized work rather than supplying new execution authority. - The draft requires Node 22.13 or newer and a matching backend deployed first, while Tavily and Dial remain marked Coming soon.

Why it matters

Approval is often slower than installation. A team member can finish a local wizard long before an administrator approves an integration, leaving a supposedly simple onboarding flow stranded between browser, terminal and running service. NanoClaw's proposal makes that gap a durable workflow instead of a temporary process that must remain open. The interesting distinction is between notifications and authority: reconnecting to an account cell should resume previously authorized local work, not become a fresh remote command surface. That boundary matters more than the number of integrations offered on the welcome screen.

Current

Inspected on 2026-09-08. The NanoClaw stable-release baseline is v2.3.0 published 2026-08-24T11:45:32Z. The main source was open when captured. Release metadata is a version boundary, not evidence that an open proposal has shipped.

Evidence

The primary source is nanocoai/nanoclaw PR #3729 (https://github.com/nanocoai/nanoclaw/pull/3729). Supporting context comes from NanoClaw proposal — pinned community portal acceptance guide (https://raw.githubusercontent.com/nanocoai/nanoclaw/7c1e25fdd544ad1a8684b8669d3fd0b84d9f6169/docs/community-portal-e2e.md); NanoClaw — current project README (https://raw.githubusercontent.com/nanocoai/nanoclaw/main/README.md). The linked records were inspected directly; related project records are not independent confirmations.

Operator take

A useful trial would close both browser and setup, approve the existing request later, then verify the originating installation resumes only that saved work. Check the actual Slack destination, not merely the success modal or queued welcome. The source's own tests use fixtures for Slack responses and the receiving service socket, so real delivery is explicitly a separate acceptance step. Also test the additional-agent path separately: it has a shorter wait and does not inherit the initial installation's durable worker. Operators should retain that asymmetry in documentation rather than presenting every approval as fully automatic. Since this is a draft with a backend dependency, a client-only update cannot be assumed to enable the intended experience.

Caveat

The proposal is open and marked draft pending human review and real-workspace acceptance. Reported integration tests use local infrastructure and Slack fixtures; completion means service handoff, not an acknowledged Slack reply. No account enrollment or integration activation was performed during curation.