Repository navigation
Proxy and VerifySsl settings in config.yml are ignored by node.js process #12956
Description
Before submitting your bug report
- I've tried finding an answer on the Continue docs site
- I'm not able to find an open issue that reports the same bug
- I've seen the troubleshooting guide on the Continue Docs
Relevant environment info
- OS: WINDOWS 11
- Continue version:
- IntelliJ IDE version: 2022.3.2 Commuity (continue-dev 1.0.33) /2024.3.3 Community (continue-dev 1.0.46)
- Model:
- config:
OR link to agent in Continue hub:Description
i am using the continue plugin in Intellij IDEA. I have configured my config.yml with specific requestOptions including proxy and verifySsl: false to navigate a corporate network with an SSL intercepting proxy. How ever the plugin continues to throw Connection error and PKIX pat building failed errors
Observed Behaviour:
The nodejs backend (Continue) seems to ignore the proxy and verifySsl configurations defined in the config.yml. The Connection only works if i manually set OS-level variables (HTTP_PROXY, HTTPS_PROXY and NODE_TLS_REJECT_UNAUTHORIZED=0) which is not ideal for end user deployment in corporate environments.
Expected Behaviour
Settings defined under requestOptions (specifically proxy and verifySsl) in the config.xml should be passed to the Node.js core process and applied to the underlying HTTP Client used to make LLM requests.
To reproduce
- Setup a config.tml with a valid apiBase and proxy under requestOptions
- Set verifySsl: false in request Options
- Attempt to send a message to the LLM
- Observe that the connection failes despite the configuration
requestOptions:
verifySsl: false
proxy: http://<<username:password>@<proxyhost>:<proxyport>
Log output
idea.log shows SSLHandShakeException: PKIX path building failed
core.log shows llm/streamChat: Connection error
Activity
wuisabel-gif commentedon Jul 10, 2026
Traced this on
main. The model-request path already honorsconfig.yamlrequestOptions. LLM calls go throughfetchwithRequestOptions({ ...this.requestOptions })(core/llm/index.ts), where proxy takes precedence over env vars (packages/fetch/src/util.ts) andverifySsl: falsemaps torejectUnauthorized: false(packages/fetch/src/getAgentOptions.ts), with top-levelrequestOptionsmerged into each model (core/config/yaml/models.ts).The gap is in non-LLM core requests that use the global
fetch()and ignorerequestOptions. The startup one that matches your core.log "Connection error" is the remote config-sync / index-cache client incore/continueServer/stubs/client.ts. It is constructed incore/indexing/CodebaseIndexer.tswhereconfig.requestOptionsis available but not passed in, so itsfetch()calls get no proxy/CA/verifySsl. Behind an HTTPS-intercepting proxy with a custom CA that fails exactly as you describe. (core/llm/fetchModels.tshas the same issue for model-list fetches.)I would like to route the config-sync client through
fetchwithRequestOptionswith the resolvedrequestOptionsand open a PR. Separately worth noting the JetBrains side only forwards the IDE proxy to core as env vars (HTTP_PROXYonly, noHTTPS_PROXY/verifySsl, and it does not readconfig.yaml), seeextensions/intellij/.../proxy/ProxySettings.kt.fix(core): honor config requestOptions in ContinueServerClient
github-actions commentedon Oct 8, 2026
This issue hasn't been updated in 90 days and will be closed after an additional 10 days without activity. If it's still important, please leave a comment and share any new information that would help us address the issue.
github-actions commentedon Oct 19, 2026
This issue was closed because it wasn't updated for 10 days after being marked stale. If it's still important, you are welcome to leave a comment and this will keep the issue open. However please note that this repo is no longer being actively maintained.
madhukargunda commentedon Oct 19, 2026
hello can you please merge this fix . this solves many developers model access issue