decolua/9router · error · Error

`Provider ${provider} uses device-code login but is not wire

Error message

`Provider ${provider} uses device-code login but is not wired in the OAuth modal device-code list`

What it means

After /authorize returns, the modal checks data.authUrl. If authUrl is null but flowType is "device_code", it means the provider registry marks this provider as device-code based, yet the provider id is missing from the modal's hardcoded deviceCodeProviders list — so the modal took the wrong (authorization-code) code path. This is an internal wiring bug guard, surfaced to the user as an error.

Source

Thrown at src/shared/components/OAuthModal.js:363

          const proxyData = await proxyRes.json();
          xaiProxyActive = proxyData.success;
          xaiServerSide = !!proxyData.serverSide;
          if (!xaiProxyActive && proxyData.reason === "port_busy") {
            throw new Error("Port 56121 in use; close the conflicting process and retry");
          }
        } catch (e) {
          if (e?.message) throw e;
          xaiProxyActive = false;
        }
      }

      setAuthData({ ...data, redirectUri, codexServerSide, xaiServerSide });

      // Guard: device_code providers return authUrl:null from /authorize. Never window.open(null)
      // (browsers coerce it to the relative path ".../null").
      if (!data.authUrl) {
        if (data.flowType === "device_code") {
          throw new Error(
            `Provider ${provider} uses device-code login but is not wired in the OAuth modal device-code list`
          );
        }
        throw new Error("No authorization URL returned from OAuth provider");
      }

      if (provider === "codex" && codexProxyActive) {
        // Proxy active: callback will be handled server-side (auto-exchange) or via channels (fallback)
        setStep("waiting");
        popupRef.current = window.open(data.authUrl, "oauth_popup", "width=600,height=700");
        if (!popupRef.current) {
          setStep("input");
        }
      } else if (provider === "xai" && xaiProxyActive) {
        setStep("waiting");
        popupRef.current = window.open(data.authUrl, "oauth_popup", "width=600,height=700");
        if (!popupRef.current) {
          setStep("input");

View on GitHub (pinned to 90b52e06ff)

Solutions

Add the provider id to the deviceCodeProviders array in src/shared/components/OAuthModal.js
Verify the provider's registry entry really has flowType "device_code"
Update/upgrade both the gateway and dashboard so registry and UI are in sync
As a user workaround, use that provider's CLI-based login instead of the dashboard modal

Example fix

// before
const deviceCodeProviders = ["github","kiro","kimi","kimi-coding","kilocode","codebuddy-cn","codebuddy-intl","qoder","grok-cli"];
// after
const deviceCodeProviders = ["github","kiro","kimi","kimi-coding","kilocode","codebuddy-cn","codebuddy-intl","qoder","grok-cli","new-device-provider"];

Defensive patterns

Strategy: validation

Validate before calling

// sync check: every registry device_code provider must be in the modal list
const missing = registryProviders.filter(p => p.flowType === "device_code" && !deviceCodeProviders.includes(p.id));
if (missing.length) throw new Error("Device-code providers not wired in modal: " + missing.map(p => p.id).join(","));

Type guard

const isWired = (provider, list) => typeof provider === 'string' && list.includes(provider);

Try / catch

try {
  await startOAuthFlow();
} catch (e) {
  if (e.message.includes("not wired in the OAuth modal")) {
    // fall back to CLI login for this provider
  }
}

Prevention

When adding a device-code provider, update both the registry and the modal's deviceCodeProviders list
Derive the list from the registry/config instead of hardcoding
Run the provider baseline verification scripts after registry changes

When it happens

Trigger: A provider added to the registry with flowType "device_code" (returns authUrl:null from /authorize) but not added to the deviceCodeProviders array in OAuthModal.js (github, kiro, kimi, kimi-coding, kilocode, codebuddy-cn, codebuddy-intl, qoder, grok-cli).

Common situations: A new device-code provider was registered in open-sse/providers/registry but the dashboard modal's hardcoded list was not updated — typically after adding a provider or upgrading versions where the registry and UI drift apart.

Related errors

AI-assisted analysis of decolua/9router@90b52e06ff (2026-08-30). Data as JSON: /api/errors/2760ccabfd94e8fb. Report an issue: GitHub.