fix: Correctly handle proxy environment variables and arguments

[semidark]

TLDR

This pull request fixes a critical issue where the NO_PROXY environment variable was ignored for LLM requests, preventing users in corporate environments from connecting to internal LLM servers. It also resolves a bug where --proxy='' failed to disable the proxy. The fix ensures that all proxy-related environment variables (HTTP_PROXY, HTTPS_PROXY, NO_PROXY) are respected, and the --proxy command-line argument works as expected.

Dive Deeper

Root Causes

1. NO_PROXY Ignored:
   The GeminiClient was using Undici’s ProxyAgent for LLM requests, but ProxyAgent does not support the NO_PROXY environment variable. As a result, requests to hosts listed in NO_PROXY were still routed through the proxy.

2. --proxy='' Bug:
   The configuration logic interpreted an empty string from the --proxy flag as falsy, causing the system to fall back to proxy environment variables instead of disabling the proxy entirely.

---

What This PR Changes

• Proxy Agent Replacement:
  Replaces ProxyAgent with EnvHttpProxyAgent in the GeminiClient. EnvHttpProxyAgent correctly reads and respects standard proxy environment variables (HTTP_PROXY, HTTPS_PROXY, and NO_PROXY), aligning LLM client behavior with the IDE client.

• Improved Proxy Configuration Logic:
  The configuration now correctly interprets --proxy='' as an explicit instruction to disable the proxy, rather than falling back to environment variables.

• Hybrid Handling of Proxy Settings:
  The setupProxyConfiguration method in GeminiClient has been refactored to intelligently handle both the --proxy argument and environment variables, ensuring correct precedence (i.e., the --proxy flag overrides environment variables).

---

Outcome

These changes result in a robust and predictable proxy implementation that:

• Follows industry proxy standards,
• Honors environment variables (HTTP_PROXY, HTTPS_PROXY, NO_PROXY),
• Respects explicit command-line overrides,
• And behaves as users in corporate environments expect.

---

Reviewer Test Plan

To validate these changes, replicate the following steps:

1. Simulate a corporate proxy environment:

   export HTTP_PROXY="http://your-corporate-proxy:8080"
   export HTTPS_PROXY="http://your-corporate-proxy:8080"

2. Exclude internal LLM server from proxy:

   export NO_PROXY="your-internal-llm-host.com,localhost,127.0.0.1"

3. Run qwen for internal LLM (using OPENAI_* variables):

   qwen "your prompt"

   • Validation: The command should succeed without connection errors; requests to your-internal-llm-host.com should bypass the proxy.

4. Test disabling proxy with --proxy='':

   qwen --proxy='' "your prompt"

   • Validation: Command should succeed; the proxy should be disabled for the request.

5. Test overriding proxy with --proxy:

   qwen --proxy='http://a-different-proxy:8888' "your prompt"

   • Validation: The request should be routed via http://a-different-proxy:8888 instead of the environment-provided proxy.

---

This reformatting aims to clearly break down the root causes, the implemented fixes, and the outcomes, with explicit steps for functional verification.

Testing Matrix

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

Linked issues / bugs

Resolves #756

[yiliang114]

Regarding --proxy without a parameter: does it typically mean enabling the proxy or not enabling it? It seems there isn’t a very standard convention. However, in the PR it’s used to indicate disabling the proxy. Is there any source or precedent for this? I mean, are there other npm packages or CLIs designed this way? I’d like to use them as a reference.

[semidark]

@yiliang114 Hmm. Now that you mention it it really seams a bit unintuitive that the proxy is disabled with an the empty proxy parameter. No, i don't have another npm example at hand that handles it the same way

[ibuky]

any progress?
it seems confliction is still to be resolved.