PicoClaw fixes OAuth scope overriding in token refreshes as gateway panics linger

PicoClaw contributors submitted PR #3378 on September 20, 2026, resolving a critical OAuth token refresh bug that severed connections to specialized cloud AI providers. In previous releases, the RefreshAccessToken routine hardcoded the requested OAuth scope string to 'openid profile email', completely ignoring custom scopes specified in OAuthProviderConfig.Scopes. When refreshing access tokens for cloud platforms like Google Cloud Platform or Antigravity infrastructure requiring specialized permissions, this hardcoded override produced refreshed tokens with insufficient authority, triggering immediate API rejection mid-run. PR #3378 passes configured provider scopes into the refresh request body, preserving required permission sets across token renewal cycles. Simultaneously, issue #3382 documents an ongoing operational hazard: the DingTalk streaming gateway continues to panic with 'send on closed channel' inside dingtalk-stream-sdk-go upon server-side WebSocket disconnects. While systemd supervisors restart the crashed process, unmanaged or containerized instances fail silently. In parallel, PR #3383 outlines the project's v0.11.0 sprint roadmap focused on agentic Web3 capabilities and ACP mesh depth.

The facts

- PR #3378 fixes RefreshAccessToken to respect configured provider scopes instead of forcing 'openid profile email'. - Prevents token refresh cycles from stripping specialized permissions required for Google Cloud and Antigravity APIs. - Issue #3382 reports recurring panics on closed channels in DingTalk stream mode when WebSocket connections drop. - The DingTalk panic forces gateway process terminations, masking underlying connection instability behind supervisor restarts. - PR #3383 publishes the v0.11.0 engineering sprint plan emphasizing module trust, agentic Web3, and ACP mesh protocol depth.

Why it matters

OAuth authentication for modern AI agents spans diverse cloud providers with distinct permission models. Hardcoding generic OIDC scopes in refresh routines breaks custom enterprise integrations, causing agents to lose cloud access hours after initial deployment. Furthermore, channel adapter panics caused by unhandled upstream WebSocket closures indicate missing defensive recovery wrappers in long-lived gateway processes.

Current

Inspected on 2026-09-21. The PicoClaw stable-channel baseline is v0.3.1 published 2026-07-03T07:37:06Z. 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: sipeed/picoclaw PR #3378 (https://github.com/sipeed/picoclaw/pull/3378). Supporting context: sipeed/picoclaw issue #3382 (https://github.com/sipeed/picoclaw/issues/3382); sipeed/picoclaw PR #3383 (https://github.com/sipeed/picoclaw/pull/3383). The source bodies and linked context were inspected. Test results quoted from contributors remain attributed reports, not independently reproduced experiments.

Operator take

Token refresh routines must mirror the exact scope parameters defined during initial authentication. Overriding configured scopes during token renewal is an antipattern that guarantees delayed authorization failures. Operators running PicoClaw with custom cloud providers should verify scope preservation in token refreshes, and environments deploying DingTalk or Feishu gateways must configure process supervisors with automatic restart policies to mitigate SDK connection panics.

Caveat

PR #3378 is an open pull request undergoing maintainer review. The DingTalk gateway panic in issue #3382 remains unmitigated in release v0.3.1, requiring external supervisor restarts until recover guards are wrapped around stream client goroutines.