NanoClaw brings OpenCode into setup through provider-owned contracts

NanoClaw's September 8 OpenCode setup layer would make an optional provider available during fresh interactive setup rather than leaving it as a manually applied runtime skill. The underlying September 7 proposal already adapts native tools, memory instructions, compaction and cancellation to NanoClaw's provider contracts. The addition matters because setup and recovery now use the provider's own adapters instead of assuming that a generic assistant can safely install or authenticate whatever runtime a user selects.

The facts

- The middle layer pins OpenCode CLI and SDK to 1.18.25 and installs 33 payload files with four contract imports. - The setup layer expands the footprint to 37 payload files and five imports, adding an interactive provider choice and installation checks. - Install and refresh verify agreement among host, runtime and setup declarations before authentication. - Host maintenance assistance requires explicit confirmation; cancellation ends the handoff rather than silently selecting another action. - Local customizations are preserved by install mode until explicit refresh, and native turns receive current instructions through one generated instruction file. - The author reports isolated native tests using cached CLI/SDK dependencies and fixture responses; live-account entitlement and production deployment are not claimed.

Why it matters

Provider portability is more than changing a model string. Authentication, native tool behavior, instruction inheritance and cancellation each carry assumptions that can break when a runtime changes. NanoClaw's stack makes those assumptions reviewable contracts. Its official positioning emphasizes local operation and isolation; a host helper is therefore a consequential boundary, not a harmless convenience feature. Explicit confirmation and provider-owned maintenance keep setup assistance from being mistaken for authority granted by ordinary model output.

Current

Inspected on 2026-09-09. The NanoClaw stable-release baseline is v2.3.0 published 2026-08-24T11:45:32Z. The main source was open (not merged) when captured. Release metadata is a version boundary; an open proposal, a merged mainline change and a packaged release remain different states.

Evidence

The primary evidence is nanocoai/nanoclaw PR #3747 (https://github.com/nanocoai/nanoclaw/pull/3747). Supporting context comes from nanocoai/nanoclaw PR #3733 (https://github.com/nanocoai/nanoclaw/pull/3733); NanoClaw — official product and isolation model (https://nanoclaw.dev/). These pages were inspected directly. Related project records explain the source cluster; they are not independent replications of contributor test claims.

Operator take

A useful evaluation should separate installation readiness from account access, then test cancellation and an interrupted refresh with a customized payload. The proposal already distinguishes these proof layers: auth checks declarations and pins without repeating container startup, while installation and image checks establish executable readiness. Review the diagnostic path as well. The author notes that context supplied to a native helper may remain in native history or provider records even after a temporary file is removed. Deleting the scratch file is not a privacy receipt for the full interaction.

Caveat

Both inspected provider layers remain open proposals. Native macOS execution was not performed, fresh dependency downloads were not proved, and installation failure does not promise rollback of every write. The reported Linux and isolated runtime checks are author evidence, not an independent end-to-end account test by illmethinks.