Repository navigation
bug(sdk/go): edge (Cloudflare Access) token is cached for the client lifetime and never reloaded #4515
Description
User Story
I use OpenShell and build automation against its SDKs. While reviewing sdk/ I hit this behavior and reproduced it with the minimal test below against main.
Problem Statement
For auth_mode: cloudflare_jwt, lazyEdgeAuth reads edge_token once and caches it forever, unlike OIDC auth, which re-reads oidc_token.json on every call.
Impact / Why This Matters
Long-running Go processes keep sending an expired Cloudflare Access token after the user re-authenticates with the CLI and edge_token is rewritten; the process must be restarted.
Acceptance Criteria
- After
edge_tokenis rewritten on disk, subsequent RPCs from an existing client use the new token.
Reproduction Steps
Write edge_token = old-token; create auth via resolveAuthProvider(&Config{AuthMode: AuthModeCloudflareJWT, Dir: dir}); call GetRequestMetadata; rewrite the file to new-token; call again: still Bearer old-token.
Suggested UX (if applicable)
No response
Environment
- OpenShell:
main@ 82977e2 (2026-10-13) - SDK: Go (
sdk/go/openshell/v1/gateway/token.go) - Toolchain: Go 1.25.4 linux/amd64, Node 22
Logs
BUG: still sending "Bearer old-token" after edge_token was refreshed on disk
Activity
rhuss commentedon Oct 14, 2026
Thanks for the report.
Confirmed on
main.edgeTokenLoader.load()(sdk/go/openshell/v1/gateway/token.go) caches the first successfully read token and never looks atedge_tokenagain, while the OIDC path is designed to re-readoidc_token.json(see #4514 for a caching issue there). Afteropenshell gateway loginrewrites the edge token, a running Go client keeps sending the old one until the process restarts.The fix can follow the OIDC path and re-read the file per call. If that's too much I/O on hot paths, a
statcheck on modification time and size before re-reading keeps it cheap. The same problem exists inedge.NewTunnelProxy(sdk/go/openshell/v1/edge/tunnel.go), which takes the token as a fixed string and sends it on every WebSocket dial, so a reconnecting tunnel would also present the stale token. Accepting a token supplier function there would cover both cases with the same loader.The evidence and acceptance criteria are complete. Next step: maintainer acceptance decision.