bug(sdk/go): stored refresh token is never used; expired logins always fall back to interactive login #4514

Activity

1. CloneOfAlex

   added the

   Bug

   issue type on Oct 13, 2026
2. github-actions

   added

   state:triage-neededOpened without agent diagnostics and needs triageOpened without agent diagnostics and needs triage

   on Oct 13, 2026
3. rhuss commented on Oct 14, 2026

   

   rhuss

   on Oct 14, 2026

   Contributor

   More actions

   📋 triage-agent

   Thanks for the report.

   Confirmed on main. The Go SDK implements the authorization_code, device_code and client_credentials grants but no refresh_token grant. oidc.readToken treats an expired access token as missing regardless of the stored refresh token, and the OIDC auth that gateway.NewClient builds (RefreshableToken over the disk token source) only re-reads oidc_token.json. It renews only if the CLI happens to refresh the file in the meantime.

   Adding the grant is straightforward. Deciding where the refreshed token goes is the harder part, because the refresh token in oidc_token.json is one credential shared with the CLI (see the discussion on #4508). If the SDK refreshes and keeps the result elsewhere, providers that rotate refresh tokens on use leave the CLI holding a revoked token. That leaves two workable designs:

   1. Shared file protocol. The SDK and the CLI both refresh and write back to oidc_token.json in the CLI's format, under a file lock, re-reading the file before refreshing (another process may already have done it) and replacing it atomically via a temp file and rename. This also fixes an existing race in the CLI itself: store_oidc_token writes the file in place without locking, so two CLI processes refreshing at once can clobber each other.
   2. CLI as the only writer. The CLI gets a command that prints a valid access token and refreshes when needed, and the SDK calls it, similar to kubectl exec credential plugins. Simpler ownership, but Go programs then need the CLI binary installed.

   For a standalone oidc.Login without a gateway (WithInMemory), an in-memory refresh is fine either way. This depends on #4508 for the issuer and client_id fields that the refresh request needs, and on #4513 for the scopes. Next step: maintainer acceptance decision, including which of the two designs to follow.
4. rhuss commented on Oct 14, 2026

   

   rhuss

   on Oct 14, 2026

   Contributor

   More actions

   One more data point that narrows the design question: the Python SDK already implements the shared-file approach (python/openshell/sandbox.py, the OIDC refresher). Before refreshing, it re-reads oidc_token.json and adopts the disk bundle if its expires_at is later, so it never refreshes with a refresh token another process has already rotated. It writes the result back atomically. If the refresh still fails with invalid_grant, it re-reads once and retries with a peer's newer refresh token. The Go SDK should mirror that behavior rather than introduce a third variant, and the CLI's store_oidc_token should switch to an atomic write so concurrent readers never see a partial file.

   Related: refreshableAuth.isTokenValid() treats a zero Expiry as valid forever. Combined with #4508 (CLI-written expires_at is ignored, so every loaded token has a zero expiry), the Go client caches the first access token for the life of the process and never re-reads the file. The fix for #4508 should include a test that an expired cached token actually triggers a re-read.
5. TaylorMutch

   added

   state:acceptedA maintainer decided OpenShell should pursue this issueA maintainer decided OpenShell should pursue this issue

   and removed

   state:triage-neededOpened without agent diagnostics and needs triageOpened without agent diagnostics and needs triage

   on Oct 21, 2026