Skip to content

bug(onboard): external provider plugin install loops and skips selected auth flow #95765

Description

@snowzlmbot

Summary

First-time onboarding can install an external model provider plugin, then immediately skip the selected provider auth flow instead of prompting for the provider credential.

This is not DeepSeek-specific. On a controlled Linux VM with the current beta installer, I reproduced the same pattern across multiple external provider plugins:

  • DeepSeek
  • Groq
  • Cerebras
  • DeepInfra
  • Chutes

In every tested round, onboarding showed the provider plugin install prompt twice, completed onboarding, never showed the selected provider credential prompt, and left the model/auth state on the default OpenAI path instead of the selected provider.

Environment

  • OpenClaw: 2026.6.10-beta.2 (87b40c7)

  • Install command:

    curl -fsSL https://openclaw.ai/install.sh | bash -s -- --beta
  • Installer behavior: beta tag detected and installed: 2026.6.10-beta.2

  • OS: Linux / Ubuntu 24.04 LTS VM

  • Node.js installed by the installer: v24.17.0

  • npm installed by the installer: 11.13.0

  • Repro method: real interactive onboarding through PTY automation with --log-level trace

  • Isolation: each provider round used a fresh named profile; after each round, the profile directory, workspace, and user systemd service for that round were removed before the next round.

Hostnames, IPs, tokens, and local filesystem identifiers are intentionally omitted/redacted.

Reproduction pattern

For each provider, run first-time onboarding in a fresh profile:

openclaw --profile <fresh-profile> --log-level trace onboard --reset --skip-channels --skip-skills --skip-ui --auth-choice <provider-auth-choice>

The tested choices were:

deepseek-api-key
groq-api-key
cerebras-api-key
deepinfra-api-key
chutes-api-key

Then:

  1. Accept the security disclaimer.
  2. Choose QuickStart.
  3. When prompted to install the provider plugin, choose the default npm install option.
  4. Observe whether onboarding continues into the selected provider credential prompt.

Matrix result

Provider Auth choice Install prompts in one onboarding run Credential prompt seen during onboarding Onboarding completed Outcome
DeepSeek deepseek-api-key 2 No Yes skipped selected auth flow after install
Groq groq-api-key 2 No Yes skipped selected auth flow after install
Cerebras cerebras-api-key 2 No Yes skipped selected auth flow after install
DeepInfra deepinfra-api-key 2 No Yes skipped selected auth flow after install
Chutes chutes-api-key 2 No Yes skipped selected auth flow after install

For all five providers, models status --plain after onboarding still printed:

openai/gpt-5.5

So the selected provider choice did not become the configured model/auth path.

Observed behavior

Example from the DeepSeek round:

Install DeepSeek plugin?
  Download from ClawHub (clawhub:@openclaw/deepseek-provider)
> Download from npm (@openclaw/deepseek-provider)
  Skip for now

The plugin install reports success, but the same onboarding run returns to another install prompt / continues to unrelated setup sections. It never reaches:

Enter DeepSeek API key

After the install step, the flow proceeds into web search / hooks / gateway setup and eventually prints onboarding complete.

The same pattern reproduced for Groq, Cerebras, DeepInfra, and Chutes.

Control checks

After each failed onboarding round, I checked the provider-specific direct auth command before cleaning the round:

openclaw --profile <same-profile> --log-level trace models auth login --provider <provider> --set-default

Results:

  • DeepSeek direct auth control: reached Enter DeepSeek API key.
  • Groq direct auth control: reached Enter Groq API key.
  • Cerebras direct auth control: reached Enter Cerebras API key.
  • DeepInfra direct auth control: reached Enter DeepInfra API key.
  • Chutes direct auth control: loaded the installed plugin and reached a Chutes-specific OAuth credential prompt (Enter Chutes OAuth client id); my API-key-only watcher timed out there, but this still confirms the installed plugin is loadable and has a credential flow after onboarding.

This means the plugin packages are being installed and are loadable after onboarding. The failure appears to be specifically in the first-run onboarding continuation path after installing a missing provider plugin.

Expected behavior

After installing the selected provider plugin during first-time onboarding, the same onboarding run should continue into that provider's auth method prompt, e.g.:

Enter DeepSeek API key

It should then set the selected provider's recommended/default model or otherwise leave model/auth state consistent with the selected provider.

Impact

  • First-time users selecting external provider plugins cannot complete provider credential setup in the onboarding flow.
  • The UI looks like a plugin install loop because the install prompt can appear twice in the same round.
  • Setup eventually completes without configuring the selected provider.
  • The final model state remains OpenAI (openai/gpt-5.5), so the next status/error points users at OpenAI missing auth instead of the provider they selected.
  • This affects multiple external provider plugins, not only DeepSeek.

Evidence captured

I captured detailed logs from a controlled Linux VM:

  • installer log with millisecond timestamps
  • per-provider onboarding raw transcript, then sanitized transcript
  • per-provider chunk-level event logs with millisecond timestamps
  • per-provider models status output
  • per-provider plugins list output
  • per-provider direct auth-control transcript
  • per-provider cleanup logs proving the profile/workspace/service were removed between rounds
  • matrix summary.json

Raw transcripts containing temporary local gateway tokens were not retained locally; only sanitized logs and status JSON were kept.

Suspected area

This looks related to the missing-provider plugin install path in onboarding/auth-choice handling.

The install step writes the plugin entry and installs the npm package, but the same onboarding run does not continue the originally selected auth choice against the newly installed plugin. Direct models auth login --provider <provider> works afterward.

Potentially relevant code paths:

  • src/commands/auth-choice.apply.plugin-provider.test.ts
    • has coverage titled installs a missing provider plugin and retries setup resolution
  • src/commands/onboarding-plugin-install.ts
  • src/commands/auth-choice.apply.ts
  • src/commands/onboard-non-interactive/local/auth-choice.plugin-providers.ts
  • src/plugins/provider-auth-choice.runtime.ts

The failing path here is real first-run interactive onboarding with missing external provider plugins.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions