[Bug]: Watch connections stuck in auth-error reconnect loop with legacy auth-provider: oidc kubeconfigs

[M77ix]

Krust version

1.4.3

macOS version

26.4.1

Kubernetes version

1.35.3

Steps to reproduce

1. Configure ~/.kube/config with a user that uses auth-provider: oidc (legacy OIDC), e.g.:

users:
- name: my-user
  user:
    auth-provider:
      config:
        client-id: gangway
        client-secret: <...>
        id-token: <...>
        idp-issuer-url: https://issuer.example/
        refresh-token: <...>
      name: oidc

2. Launch Krust and select the cluster/namespace.
3. Pods view loads correctly (initial list succeeds).
4. Open Deployments (or any other watch-backed resource view).

Expected behavior

Deployments list loads, just like Pods. Watches refresh the id-token using the refresh-token the same way kubectl and k9s do.

Actual behavior

The Deployments view stays on the "connecting" loader forever. Logs show the watch client repeatedly hitting auth errors and reconnecting every ~2s with no recovery.

Logs / screenshots

Logs

[PREFETCH] list=264ms snapshot=1ms pods=117
[POD-WATCH] client=2ms
[POD-WATCH] auth error, invalidating client and reconnecting...
[POD-WATCH] reconnecting in 2s
[POD-WATCH] client=4ms
[POD-WATCH] auth error, invalidating client and reconnecting...
[POD-WATCH] reconnecting in 2s
... (loop continues indefinitely)

[vanchonlee]

Thanks for the detailed report. This should be addressed in Krust v1.5.0.

The release includes the kube OIDC support path needed for legacy auth-provider: oidc kubeconfigs, so watch-backed views should now use the same refreshed credentials path instead of staying in the auth-error reconnect loop.

Could you update and try again?

brew upgrade --cask vanchonlee/tap/krust

I will keep this issue open until you can confirm it is fixed in your environment. If it still loops, please send the new logs around the first watch reconnect after opening Deployments, plus whether Pods still list successfully.