Provider sign-in is more reliable on WSL

What changed

Roder 0.1.9 improves provider authentication from the CLI. Codex, SuperGrok, and Kimi Code sign-in now print the sign-in URL before attempting to open a browser. If automatic browser launch fails, the URL remains visible so you can paste it into the right browser manually instead of restarting the login flow.

The browser launcher also handles WSL more deliberately. On WSL it tries Windows-friendly launch commands before falling back to the standard Linux opener, which makes OAuth and device-code sign-in less brittle for developers running Roder inside a Linux shell with their browser on the Windows side.

Kimi Code now supports a first-class API-key login command:

roder auth login kimi-code --api-key
roder auth login kimi-code --api-key "$KIMI_CODE_API_KEY"
roder auth status kimi-code
roder auth logout kimi-code

Passing --api-key without a value prompts for the key interactively. Passing a value stores it directly in the user provider config.

Why it matters

• Provider setup is easier to recover. When a browser does not open automatically, the CLI has already printed the URL you need.
• WSL users get a path that matches how their machines are actually set up: terminal in Linux, browser on Windows.
• Kimi Code users no longer have to choose subscription OAuth for every setup. API-key based teams can use the same roder auth workflow as other provider credentials.
• roder auth status kimi-code reports when an API key is configured, and roder auth logout kimi-code removes the stored key from config.
• App-server clients also see Kimi Code API-key state through the auth status path, so desktop or IDE surfaces can show whether the provider is ready without guessing from config files.

Using it

Use the OAuth path when you want the Kimi Code subscription login:

roder auth login kimi-code --oauth

Use the API-key path when your workflow is based on a Moonshot or Kimi Code key:

roder auth login kimi-code --api-key

For Codex and SuperGrok, keep using the existing login commands. The visible sign-in URL and WSL browser fallback are part of the normal flow.