fix: apply auth type from arg or env variables

[reneleonhardt]

Bugfix

Run local LLM when passing --openai-api-key or configuring env variables

After the "Get started" wizard has been completed, or settings.json has been configured manually, the command line flag --openai-api-key and env variables are not being respected anymore to determine the authType.

For example, if settings.json contains { "selectedAuthType": "qwen-oauth" }, local LLMs can't be used anymore by providing the OPENAI_... env variables, the login page is being opened instead.

This implementation configures this setting now:

1. command line arg --openai-api-key "my-key" implicitly sets "openai"
2. env variables or .env file (i.e. OPENAI_API_KEY) sets their corresponding authType
3. { "selectedAuthType": "openai" } in settings.json is used
4. If authType couldn't be determined, the "Get started" wizard is run (user has to choose between qwen-oauth and openai) in order to fill settings.json

Workaround for the current release:
The user always has to keep settings.json in sync with his intended use, for example if he now passes the --openai-api-key flag or switches providers in the .env file, i.e. from OPENAI to GEMINI or GOOGLE (vertex.ai).

Dive Deeper

Please note that not only OPENAI is affected, even if the env is configured with other providers, only settings.json is being respected at the moment to determine the authType.

This also means, that the user has to change settings.json after the "Get started" wizard if he doesn't want to use qwen-oauth or openai.

Reviewer Test Plan

Install the current release, then try all steps:

1. Complete "Get started" with qwen-oauth (first option) -> login dialog page is opened
2. Run with --openai-api-key my-key -> login dialog page is opened nevertheless
3. Run with OPENAI_API_KEY=my-key -> login dialog page is opened nevertheless
4. Run with .env containing OPENAI_API_KEY=my-key -> login dialog page is opened nevertheless
5. Change settings.json to { "selectedAuthType": "openai" } -> OPENAI is being used (no login page)

Checkout/install this PR, delete settings.json, then retry all steps:

1. Complete "Get started" with qwen-oauth (first option) -> login dialog page is opened
2. Run with --openai-api-key my-key -> OPENAI is being used (no login page although settings.json contains qwen-oauth)
3. Run with OPENAI_API_KEY=my-key -> OPENAI is being used (no login page although settings.json contains qwen-oauth)
4. Run with .env containing OPENAI_API_KEY=my-key -> OPENAI is being used (no login page although settings.json contains qwen-oauth)
5. Change settings.json to { "selectedAuthType": "openai" } -> OPENAI is being used (no login page)

Keep in mind that qwen doesn't respect Ctrl+C or Escape even if (Press ESC to cancel) is being displayed while waiting for the qwen-oauth login page, the node process has to be stopped (killall -9 node).

Testing Matrix

	🍏	🪟	🐧
npm run	❓	❓	❓
npx	❓	❓	❓
Docker	❓	❓	❓
Podman	❓	-	-
Seatbelt	❓	-	-

Linked issues / bugs

• Fixes Qwen Code ignoring .env and environmental variables - Not using local llm #599

[macpczone]

I just tried your branch and it works now with a local model. When do you think your fix will be merged with the main one?

[reneleonhardt]

Thank you for trying my fix, if you want you can install it or write an alias to use it until it's released for more real-life testing!

I'm no maintainer here and I don't have permissions to request a review.
You can see in https://github.com/QwenLM/qwen-code/blob/main/.github/CODEOWNERS that a review should've been requested already.
But the comment seems a bit misleading, this automatism is lacking transparency (not visible for contributors, the Reviewers list is empty as you can see, no request shown), and anyone in that team can choose to decline a request without notifying contributors:

# By default, require reviews from the release approvers for all files.
* @google-gemini/gemini-cli-askmode-approvers

Alternatively, a workflow could assign reviewers at random, I guess we just have to be patient 😄

After looking at the merged pull requests during the last week it seems it could only take a week until it gets reviewed, maybe even faster.
But keep in mind that reviewers can always decide to close pull requests, sometimes even without any reason, happened to me many times... let's just hope for the best, my fix worked beautifully here 🤞

[Mingholy]

I found some issue testing the auth switching behavior. Changes are required to keep the auth switch working.

[Mingholy]

This will break the auth type switching behavior.
Currently, switching the authentication type will mutate user scope settings, which will be merged here to take effect. With the overwrite process, the mutation will not take effect.

qwen-code/packages/cli/src/ui/components/AuthDialog.tsx

Line 104 in 4e7a7e2

onSelect(AuthType.USE_OPENAI, SettingScope.User);

We may have two options:

1. Consider users' auth selection as system override, which will always take the highest priority;
2. Add merge strategy in loadCliConfig to respect env variables and cli arguments.

[reneleonhardt]

Thank you for finding this issue, which option would be preferable?

I can't find a merge strategy anywhere, loadCliConfig() is already being called from main() with settings.merged and my addition there is to respect env and args 😄

Do you have a a quick example (pseudo) code for both options?

I guess by option 1 you mean overriding systemSettings inside loadSettings() itself which happens much earlier in main() before env and args have been processed?

If you already know an acceptable solution, feel free to push a commit, maintainers have all permissions.