• AuthDeck

The TUI as a Routing Layer

If AuthDeck is the bridge, the terminal UI is where you steer it. This turned out to be the most interesting part of the project—and the least conventional.

Most proxies are configured once and forgotten. AuthDeck instead asks, at the moment a request arrives, which provider should handle it?

Requests as Events

When a request hits the proxy, it doesn’t get forwarded immediately. It’s queued, and the TUI lights up:

New request — select provider:
▸ GET /api/users  14:30:21

[1-9] select provider  [↑↓] navigate

Nothing moves until you choose. That’s intentional. The selection is a runtime decision, made in context, not a setting buried in a config file.

Opening the Browser

For interactive providers, choosing a provider kicks off the Authorization Code flow. AuthDeck opens the browser with the provider’s authorization URL and waits for the callback. The TUI shows “Opening browser…” until the code comes back.

One subtle bug taught me a lesson here: I forgot to clear that state after the callback, so the UI sat stuck on “opening browser” forever. A simple missing message—but a reminder that async UI state always needs an exit path.

Turning configuration into interaction changes how a tool feels. The TUI isn’t decoration—it’s the control plane. The proxy waits for a human decision exactly when that decision matters, and nowhere else.