NanoClaw routes OpenCode authentication through Iron Proxy gateway

NanoClaw opened PR #3825 on September 17, 2026, enabling OpenCode to authenticate through Iron Proxy using managed API keys and native ChatGPT sign-ins. The architecture cleanly separates developer model identity from the gateway that manages credential storage and token refresh. Simultaneously, NanoClaw resolved significant installation friction on Linux systems: PR #3844 and PR #3847, both merged on September 17, fixed bootstrap hangs where setup.sh attempted sudo commands without a TTY. By introducing non-root corepack pnpm installation into ~/.local/bin and falling back to user-owned npm prefixes, NanoClaw ensures unprivileged Linux environments install reliably without blocking on missing passwords. These setup fixes remove one of the most common friction points encountered by developers deploying agents into shared server infrastructure.

The facts

- PR #3825 allows OpenCode setups to authenticate via Iron Proxy with credential persistence and OAuth renewal handled by Iron Control. - Preserves grant identifiers during re-authentication and prevents shared-host multi-agent credential collisions. - Merged PR #3847 adds corepack enable --install-directory ~/.local/bin pnpm, enabling non-root pnpm installation on headless Linux instances. - Merged PR #3844 stops setup.sh from hanging when global node_modules is root-owned by falling back to user-owned npm directories. - PR #3849 addresses Gemini turn serialization errors where assistant functionCall turns in leading positions cause permanent 400 session deadlocks.

Why it matters

Developers frequently work on shared servers or headless containers where they lack root privileges. Installing global packages via sudo in background scripts invariably leads to silent hangs when sudo prompts for passwords without an interactive terminal. Fixing these bootstrap seams makes agent software deployable across cloud VMs and restricted corporate workstations. Furthermore, decoupling OpenCode's authentication from raw API keys reduces credential sprawl across developer workspaces, ensuring that automated agents do not retain unmanaged access tokens.

Current

Inspected on 2026-09-18. 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 #3825 (https://github.com/nanocoai/nanoclaw/pull/3825). Supporting context: nanocoai/nanoclaw PR #3844 (https://github.com/nanocoai/nanoclaw/pull/3844); nanocoai/nanoclaw PR #3847 (https://github.com/nanocoai/nanoclaw/pull/3847). The source bodies and linked context were inspected. Test results quoted from contributors remain attributed reports, not independently reproduced experiments.

Operator take

Moving credentials out of individual tool configs and into a proxy gateway like Iron is sound operational hygiene. Equally important is the bootstrap fix: when setup scripts fail silently on standard Linux distributions, users abandon the project. Fixing the non-root install path is a massive win for reliability, especially on Linux distros with hardened system package managers. Administrators can now automate container and VM provisioning without baking elevated credentials into deployment templates.

Caveat

The Iron Proxy integration is part of an open PR stack that depends on underlying gateway refactorings (#3818, #3824) and remains unmerged. The bootstrap fixes require ~/.local/bin to be included in the user's PATH environment. Multi-tenant instances must ensure Iron Control permissions are isolated.