Repository navigation
[Feature]: Provide a way to refresh authentication #37
Description
Is your feature request related to a problem?
I send OpenTelemetry signals to a collector hosted as a GCP Cloud Run service. This has an authentication timeout of 60min.
At the moment there is no (obvious to me, maybe I missed it) mechanism to acquire/refresh authentication, which means after 60min I'll have data loss.
Describe the solution you'd like
I'd like to be able to set up a script/binary so that it can be called when requests are rejected with 401/403/whatever, and it runs to refresh authentication.
Prior art: Claude has support for this via "dynamic headers".
My script (for claude) basically checks Google Application Default Credentials are set and not expiring soon (and if not, calls gcloud auth login --update-adc), then shoves gcloud auth print-access-token into {"Authorization": "Bearer {here}"} (JSON as claude's integration allows a set of headers to be returned).
Describe alternatives you've considered
- Perhaps the plugin itself might implement authentication - but probably not as that would then increase the scope to every potential backend's authentication options.
- Perhaps a hook that fires pre-prompt - but now I see that an opencode plugin is a set of hooks already. Plus, that might not actually be often enough depending on the time any given prompt needs to get an answer back.
Telemetry type
Configuration, Metrics
Additional context
No response
Checklist
- I have searched existing issues and discussions for similar feature requests
- I have checked the changelog to see if this already exists
Activity
petemounce commentedon Apr 30, 2026
Is there any complexity to resolve regarding credential acquisition crossing over the exporter export intervals? As in, there are 2 exporters (3 if traces become supported) both independently making requests on independent cadences. They share the credential acquisition machinery; it will need to be gated.
Re: refreshing credentials - the approach you have a preference for trades off lower frequency/cost of auth calls vs higher risk of data-loss (with short warning window) in the event of credentials failure. I would hazard that most clients will not prominently display failed observability publishing to users, and I would further hazard that most users will not be subject matter experts to debug, and further are unlikely to care about this data-loss as it's not their data-loss; it's orthogonal to whatever they might be working on.
That makes me think the chance of recovery is slim too none in the event of failure to auth. Would it be reasonable to use a periodic refresh (scheduled for every half-expiry), and publish auth_expiry and auth_duration metrics to allow centralised detection of authentication problems? My thought is that "normal" looks like
auth_expiry > (auth_duration/2 - some_jitter)for any given client. An alert might be defined for telemetry going silent, and an investigation can conclude auth if they see auth_expiry dropping below half auth_duration before the silence.petemounce commentedon Apr 30, 2026
(also, and this should have been in my original comment; thank you for writing and maintaining this plugin, I really appreciate it!)
petemounce commentedon May 6, 2026
Just checking back in on this - it works with a couple of caveats:
403s of first-request auth-failure. It'd be nice from an operator UX point of view to execute the helper on opencode startup or first-prompt if the helper's env-var is set to reduce that to 0.petemounce commentedon May 9, 2026
Startup pre warm is likely to cover most of the operator UX in practice.
Re: expiry/TTL - I think (in the gcp case anyhow) these are base64 encoded JWTs? If so, expiry ought to be baked into the token itself.