What happened?
A previous PR, #4100, mentioned something similar; however, it was not merged, and the related proxy design has been refactored. In the current implementation:
|
export function setGlobalProxy(proxy: string) { |
|
setGlobalDispatcher( |
|
new ProxyAgent({ |
|
uri: proxy, |
|
headersTimeout: DEFAULT_HEADERS_TIMEOUT, |
|
bodyTimeout: DEFAULT_BODY_TIMEOUT, |
|
}), |
|
); |
|
} |
A simple ProxyAgent is assigned if an HTTP(S) proxy is detected in the environment. It plainly intercepts all traffic, including the localhost/127.0.0.1, hindering the local services Gemini CLI sends to.
It seems like a better choice to switch to the EnvHttpProxyAgent as proposed in #4100?
What did you expect to happen?
The global proxy can correctly fetch NO_PROXY/no_proxy from the system environment and forward local traffic directly.
Client information
Client Information
> /about
│ CLI Version 0.36.0-nightly.20260317.2f90b4653 │
│ Git Commit 0df9498 │
│ Model gemini-3-pro-preview │
│ Sandbox no sandbox │
│ OS linux │
│ Auth Method gemini-api-key
Login information
API key
Anything else we need to know?
None
What happened?
A previous PR, #4100, mentioned something similar; however, it was not merged, and the related proxy design has been refactored. In the current implementation:
gemini-cli/packages/core/src/utils/fetch.ts
Lines 193 to 201 in 0df9498
A simple
ProxyAgentis assigned if an HTTP(S) proxy is detected in the environment. It plainly intercepts all traffic, including thelocalhost/127.0.0.1, hindering the local services Gemini CLI sends to.It seems like a better choice to switch to the
EnvHttpProxyAgentas proposed in #4100?What did you expect to happen?
The global proxy can correctly fetch NO_PROXY/no_proxy from the system environment and forward local traffic directly.
Client information
Client Information
Login information
API key
Anything else we need to know?
None