Don't Optimize Away the Point
A few weeks in, I added what felt like an obvious optimization. If a provider already had a valid cached token, why ask again? So AuthDeck remembered the last provider you picked and quietly reused it. Faster, fewer keystrokes, less friction.
It was also completely wrong.
The Bug That Wasn’t a Bug
The behavior was intentional—I wrote it. But the effect was that requests started resolving against some provider without me choosing one. The whole reason AuthDeck exists is that provider selection is a runtime decision. A default that skips that decision doesn’t optimize the tool; it erases what makes it useful.
The tell was the phrase I caught myself saying out loud: “It just takes some provider.” When a tool surprises you about the one thing it’s supposed to be explicit about, the optimization is the bug.
Choosing Explicitness Over Convenience
The fix was to delete the fast path entirely. Every request now goes through the same path:
- The request appears in the TUI.
- You pick a provider.
- AuthDeck resolves—or reuses—a token for exactly that provider.
The token cache still does its job. Selection happens every time; re-authentication does not. Those two concerns were never the same, and conflating them is what caused the mess.
The General Lesson
Caching is safe when it returns the same answer for the same question. Here, the question was “which provider?” and my cache answered “the last one.” That’s a different question. Optimizing a decision away is rarely an optimization when the decision is the product.
It’s tempting to smooth over a choice once you’ve seen it made. But some choices are the interface. AuthDeck’s job isn’t to avoid asking—it’s to make asking cheap. A cached token should save a round trip, never a decision.