`/connect` bypasses plugin auth prompts (can open the wrong OAuth flow)

[garysassano]

Description

When connecting to a provider via the TUI /connect flow, OpenCode does not run the plugin’s auth.methods[].prompts UI before calling authorize(). This prevents plugins from collecting required inputs (e.g., IAM Identity Center Start URL + SSO region) and can lead to the wrong login flow being opened (e.g., AWS Builder ID email page instead of the org’s IAM Identity Center username portal).

By contrast, opencode auth login does run the plugin prompt flow correctly.

Expected behavior

/connect should behave like opencode auth login:

• If an auth method defines prompts, OpenCode should display them and pass the collected inputs to authorize(inputs).
• This should happen for both OAuth and API auth methods.

Actual behavior

• /connect selects the provider/method and invokes authorize() with no (or incomplete) inputs.
• Plugins that rely on prompts to choose between multiple flows can’t do so.
• In the AWS case, it often opens the AWS Builder ID page (email prompt) because the plugin never receives an IAM Identity Center Start URL / sso_region.

Why this matters (real example)

For AWS IAM Identity Center device auth, plugins typically need:

• start_url (Identity Center Start URL) to send users to the org-specific device page
• idc_region (sso_region) for OIDC token exchange

Without prompting, the provider may:

• fall back to a default flow (Builder ID)
• or fail, forcing users to leave the TUI and use opencode auth login anyway

Repro steps (provider-agnostic)

1. Use any plugin/provider auth method that defines auth.methods[].prompts (e.g. start_url and idc_region) and requires those inputs to choose the correct OAuth flow.
2. Start OpenCode TUI.
3. Run /connect and select that provider/method.
4. Observe that OpenCode does not show the plugin’s prompts and calls authorize() without the required inputs, causing the provider to:
   • open the wrong login page (common with AWS Builder ID vs IAM Identity Center), or
   • fail and require a separate login flow outside /connect.
5. Run opencode auth login for the same provider/method.
6. Observe that OpenCode does show the prompts and passes inputs to authorize(inputs) as expected.

Proposed fix

In the /connect flow, if the selected auth method includes prompts:

• Render those prompts in the TUI
• Collect inputs
• Call authorize(inputs) (or authorize for API methods)

Workarounds

• Use opencode auth login instead of /connect
• Or preconfigure provider-specific defaults in config files/env vars (not always possible / not discoverable)

Environment

• OpenCode version: 1.2.10 (adjust if different)
• OS: Linux (adjust if different)
• Example impacted scenario: AWS IAM Identity Center device auth (Start URL + SSO region prompts)

Plugins

No response

OpenCode version

1.2.10

Steps to reproduce

No response

Screenshot and/or share link

No response

Operating System

No response

Terminal

No response

[github-actions]

This issue might be a duplicate of or related to existing issues. Please check:

• [FEATURE]: Support for dynamic auth prompts and CLI login improvements #12118: Feature request for dynamic auth prompts support in the connect dialog — this directly addresses the same gap (plugin-defined prompts not being rendered in the TUI /connect flow)
• Plugin OAuth auth methods silently ignored (shadowed by other plugins) #10063: Plugin OAuth auth methods being silently ignored — related plugin auth flow issue

If your issue is distinct from these, feel free to clarify how it differs.

[garysassano]

• /connect does prompt for values sometimes, but only for the built-in API key path. It’s not the plugin “choosing not to ask”; the current /connect OAuth path has no
  support for plugin prompts/inputs.

• Here’s what OpenCode’s TUI /connect dialog actually does:

  • If the selected auth method is api, it renders a DialogPrompt and then saves the key.
  • If the auth method is oauth, it immediately calls sdk.client.provider.oauth.authorize({ providerID, method }) with no inputs and proceeds with auto/code handling.
    Source: packages/opencode/src/cli/cmd/tui/component/dialog-provider.tsx

• By contrast, opencode auth login (CLI) does iterate over method.prompts, collects inputs, and passes them into method.authorize(inputs).
  Source: packages/opencode/src/cli/cmd/auth.ts

• So: with today’s OpenCode, a plugin like Kiro can’t make /connect ask for “IDC start URL + region” because /connect never requests/receives those prompt definitions and the OAuth authorize call doesn’t include an inputs object.

• If you want /connect to ask for start URL/region, it needs an upstream OpenCode change:

  • TUI /connect must render auth.methods[].prompts for oauth methods (like opencode auth login does), and
  • the /provider/{id}/oauth/authorize request shape must accept/forward those inputs to the plugin’s authorize(inputs).