RFC-0070: thv llm subcommand for LLM gateway authentication

[jerm-dro]

Summary

Proposes a thv llm command group that bridges AI coding tools to OIDC-protected LLM gateways. Two authentication modes cover the full spectrum of tools:

• Proxy mode — localhost reverse proxy for static-key-only tools (Cursor) that injects fresh OIDC tokens
• Token helper mode — thv llm token prints a fresh JWT for OIDC-capable tools (Claude Code)

A single thv llm setup command detects installed tools, configures them, starts the proxy, and handles OIDC login — extending ToolHive's existing MCP auto-wiring to LLM gateway access.

Key design decisions

• Builds on ToolHive's existing config persistence (UpdateConfig()), secrets provider (ScopeLLM), client config editing (pkg/client/config_editor.go), and OIDC infrastructure
• Config types live in pkg/llm/config.go; implementation details in pkg/llm/internal/
• Client configs modified in place without backups, matching MCP auto-wiring convention
• Claude Code and Cursor illustrate the two modes; additional tools evaluated case-by-case

[JAORMX]

Would this be settable/usable via the HTTP API? That is, could the UI set this up?

[jerm-dro]

This will need to be updated to explain how a single command can be used to login once to provide access to automatically wire MCP servers and LLM gateways, where both require the same oidc auth.

[jerm-dro]

Out of scope for this RFC. The OIDC flow for MCP tool authentication is fundamentally different from LLM gateway auth — unifying them into a single sign-on would add significant complexity. Two separate logins is acceptable for now; a unified login can be explored in a future RFC if there's demand.

Added a non-goal entry to the RFC to make this explicit.

[jerm-dro]

@JAORMX Good question. This RFC is scoped to the CLI only — thv llm setup runs locally, patches local tool config files, and manages a local proxy process. The HTTP API isn't in scope here.

That said, the config model and core logic are designed to be reusable, so exposing LLM gateway configuration via the HTTP API (e.g., for UI-driven setup) is a natural follow-up. Added a non-goal entry to make this explicit.