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:
- Accept the security disclaimer.
- Choose QuickStart.
- When prompted to install the provider plugin, choose the default npm install option.
- 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:
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:
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.:
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.
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:
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 -- --betaInstaller behavior: beta tag detected and installed:
2026.6.10-beta.2OS: Linux / Ubuntu 24.04 LTS VM
Node.js installed by the installer:
v24.17.0npm installed by the installer:
11.13.0Repro method: real interactive onboarding through PTY automation with
--log-level traceIsolation: 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:
The tested choices were:
Then:
Matrix result
deepseek-api-keygroq-api-keycerebras-api-keydeepinfra-api-keychutes-api-keyFor all five providers,
models status --plainafter onboarding still printed:So the selected provider choice did not become the configured model/auth path.
Observed behavior
Example from the DeepSeek round:
The plugin install reports success, but the same onboarding run returns to another install prompt / continues to unrelated setup sections. It never reaches:
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:
Results:
Enter DeepSeek API key.Enter Groq API key.Enter Cerebras API key.Enter DeepInfra API key.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.:
It should then set the selected provider's recommended/default model or otherwise leave model/auth state consistent with the selected provider.
Impact
openai/gpt-5.5), so the next status/error points users at OpenAI missing auth instead of the provider they selected.Evidence captured
I captured detailed logs from a controlled Linux VM:
models statusoutputplugins listoutputsummary.jsonRaw 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.tsinstalls a missing provider plugin and retries setup resolutionsrc/commands/onboarding-plugin-install.tssrc/commands/auth-choice.apply.tssrc/commands/onboard-non-interactive/local/auth-choice.plugin-providers.tssrc/plugins/provider-auth-choice.runtime.tsThe failing path here is real first-run interactive onboarding with missing external provider plugins.