continuedev / continuedev/continue
CLI: onboarding prompts even when ~/.continue/config.yaml already exists
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 36k
- Forks
- 5.4k
- PR merge metrics
- No merged PRs in 30d
Description
Summary
The Continue CLI (cn) prompts the user to log in or enter an Anthropic API key on every startup, even when ~/.continue/config.yaml already contains a complete, working configuration (e.g. a local LLM that needs no API key). The IntelliJ plugin has no equivalent gate and simply uses the config it finds.
Repro
- Fresh
~/.continue/containing only a validconfig.yamlfor a local LLM (noauth.json, no.onboarding_complete, noCONTINUE_API_KEY). - Run
cn. - Greeted with:
How do you want to get started? 1. ⏩ Log in with Continue 2. 🔑 Enter your Anthropic API key - Neither option is desired — the user already has a working config.
Reproduces on multiple machines.
Cause
extensions/cli/src/onboarding.ts:138 (initializeWithOnboarding) runs before config resolution. runOnboardingFlow short-circuits on:
--config <path>(line 55-57)CONTINUE_USE_BEDROCK=1(line 60-65)- non-TTY /
NODE_ENV=test/CI=true/VITEST=true/GITHUB_ACTIONS=true(line 68-86) ~/.continue/.onboarding_completeflag (line 161)
It does not check whether ~/.continue/config.yaml already exists, even though extensions/cli/src/configLoader.ts:128 will happily load it when loadAuthConfig() returns null.
Compounding the problem: passing --config <path> once does not mark onboarding complete. runOnboardingFlow returns false when configPath is provided (line 56), so markOnboardingComplete() at line 165 is skipped. Every plain cn invocation re-prompts.
Expected behaviour
Parity with the IntelliJ plugin and with the existing configLoader.ts:128 fallback: when ~/.continue/config.yaml exists and the user is unauthenticated (no auth.json, no CONTINUE_API_KEY), treat them as already configured and skip onboarding.
Bonus fix: --config <path> should also mark onboarding complete after a successful load, so a one-time --config invocation has lasting effect.
Workaround
touch ~/.continue/.onboarding_complete
Confirmed working. After this, plain cn falls through to ~/.continue/config.yaml via the unauthenticated branch in configLoader.ts.
Proposed fix
In runOnboardingFlow, between the --config short-circuit and the option prompt, add:
const defaultConfigPath = path.join(env.continueHome, "config.yaml");
if (fs.existsSync(defaultConfigPath)) {
return false; // Existing config — no onboarding needed.
}
…and in initializeWithOnboarding, mark onboarding complete after a successful --config load too.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading extensions/cli/src/onboarding.ts, especially runOnboardingFlow and initializeWithOnboarding, then compare their behavior with the fallback in extensions/cli/src/configLoader.ts:128. Reproduce with a valid ~/.continue/config.yaml and no auth files; done means plain cn skips onboarding and a successful --config invocation has the stated lasting effect.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- cli
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 74/100