NanoClaw proposes gateway choice without changing provider login

NanoClaw contributors are separating two decisions that can look deceptively similar in an installer: which model provider an agent uses, and which gateway holds the credentials for that access. The September 15 setup proposal adds gateway selection to advanced setup while preserving OneCLI in the simple path and retaining existing installations' choices. Related proposals add an Iron Proxy option and a shared credential-connection interface. These are linked pieces of an open stack, not a claim that users should replace their gateway today.

The facts

- PR #3818 leaves OneCLI first and default in simple setup, with gateway choice exposed in advanced setup. - The same proposal says existing installations retain their selected gateway and provider-login choices remain independent. - PR #3817 offers Iron Proxy with optional Iron Control and describes a separate NanoClaw approval front over pinned upstream Iron. - The Iron proposal says its internal credential proxy listens on loopback and the approval front validates sessions before releasing requests and responses. - PR #3824 defines metadata lookup, save and keep operations for credentials, with missing selected-gateway adapters failing rather than silently falling back.

Why it matters

This is an authority-design change disguised as setup UI. Provider identity answers whose model account is used; gateway custody answers where secrets live and which policy path mediates their use. Keeping those choices independent can make the system easier to extend without teaching each provider adapter every gateway's management API. The conservative default is important: optionality that silently migrates credentials would create a very different operational event. Here the proposed product boundary preserves existing selections while adding an explicit path for operators who want another custodian.

Current

Inspected on 2026-09-16. The NanoClaw stable-channel baseline is v2.3.0 published 2026-08-24T11:45:32Z. The primary source was open (not merged) when captured. Mainline merges, open proposals and packaged releases are distinct availability states; the release baseline does not establish that a proposal has shipped.

Evidence

Primary evidence: nanocoai/nanoclaw PR #3818 (https://github.com/nanocoai/nanoclaw/pull/3818). Supporting context: nanocoai/nanoclaw PR #3817 (https://github.com/nanocoai/nanoclaw/pull/3817); nanocoai/nanoclaw PR #3824 (https://github.com/nanocoai/nanoclaw/pull/3824); NanoClaw — official product README (https://raw.githubusercontent.com/nanocoai/nanoclaw/main/README.md). The source bodies and linked context were inspected. Test results quoted from contributors remain attributed reports, not independently reproduced experiments.

Operator take

Review the stack as a whole before testing it. Check setup preservation, credential naming and the approval path together, since a green screen test does not establish that a held request reaches the intended decision-maker. The Iron proposal reports Docker tests using fixture credentials and a controlled upstream, which are useful boundary checks but not live provider-account acceptance. A disposable installation should demonstrate removal and reinstall as well as initial setup. Existing operators should wait for merged, supported guidance unless they are deliberately evaluating the branch; no credential rotation or cross-gateway migration is implied by this report.

Caveat

The selected proposals were open when inspected. Reported host, container and gateway tests are contributor evidence, not an independent production trial. The Iron proposal explicitly excludes real provider accounts and chat channels from its described tests, so OAuth continuity and live approval delivery remain separate acceptance questions.