Agent ignores http.proxy and HTTPS_PROXY when HTTP/2 is enabled (bypasses corporate proxy)

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

With HTTP/2 enabled (the default), the agent’s model requests do not go through the configured HTTP proxy. They connect directly to agentn.global.api5.cursor.sh, ignoring both the http.proxy setting (with http.proxySupport: override) and the standard proxy environment variables (HTTPS_PROXY, NODE_USE_ENV_PROXY=1). Only with “cursor.general.disableHttp2”: true does the agent use the proxy. In networks where all HTTPS egress must go through a proxy, the agent either bypasses it or users must give up HTTP/2.

Actual behavior

  • The Chromium network service honours the proxy (startup requests reach it).
  • The extension host opens direct TLS connections to agentn.global.api5.cursor.sh:443 (agent.v1.AgentService/Run, HTTP/2) and api2.cursor.sh, never touching the proxy.
  • With “cursor.general.disableHttp2”: true, the same turn goes to api2.cursor.sh over HTTP/1.1 through the proxy and completes normally.

Likely cause
In extensions/cursor-always-local/dist/main.js, createHttp2Transport builds connect-node’s Http2SessionManager(baseUrl, …, options) with only TLS options (ca, minVersion, DNS lookup). There is no proxy agent and no createConnection, and nothing reads http.proxy or proxy env vars on this path. Node’s http2.connect has no built-in proxy support, so it connects directly. The HTTP/1.1 transport uses an https.Agent and does respect the proxy.

Precedent
This gap was already fixed for the Cursor CLI: per a Cursor staff reply on 2026-06-16, the CLI’s native http2.connect() now honours HTTPS_PROXY. The IDE bundle (3.22.12) has no equivalent: its createHttp2Transport passes no proxy and no createConnection to Http2SessionManager.

Suggested fix
When a proxy is configured (http.proxy, or HTTPS_PROXY/https_proxy, honouring NO_PROXY), open a CONNECT tunnel to the proxy and pass that socket through the session manager’s nodeOptions.createConnection (TLS with ALPN h2 over the tunnel), the same pattern as the CLI fix. This keeps HTTP/2 and makes the agent proxy-aware like the rest of the editor.

Related: forum thread #164325 (always-local extension host ignoring http.proxy).
Workaround today: “cursor.general.disableHttp2”: true, which gives up HTTP/2 for all agent traffic.

Steps to Reproduce

  1. Run any local HTTP CONNECT proxy, e.g. on 127.0.0.1:8080.
  2. In user settings.json add:
    {
    “http.proxy”: “http://127.0.0.1:8080”,
    “http.proxySupport”: “override”
    }
    (Same result when launching Cursor with HTTPS_PROXY=http://127.0.0.1:8080 and NODE_USE_ENV_PROXY=1.)
  3. Restart Cursor, open a local folder, start a Local agent chat (not Cloud) and send any prompt.
  4. Watch the extension host’s connections, e.g. lsof -nP -iTCP on the “extension-host (always-local)” / “Agents Window” processes: the agent connects directly to agentn.global.api5.cursor.sh:443 instead of the proxy.
  5. Set “cursor.general.disableHttp2”: true, restart, send the same prompt: the request now goes through the proxy (api2.cursor.sh over HTTP/1.1).

Expected Behavior

When a proxy is configured (http.proxy, or HTTPS_PROXY/https_proxy, honouring NO_PROXY), the agent’s requests to *.api5.cursor.sh and api2.cursor.sh go through it as an HTTP CONNECT tunnel, with HTTP/2 still used inside the tunnel. This is what already happens over HTTP/1.1 when HTTP/2 is disabled, and what the rest of the editor does. A proxy should not force users to turn HTTP/2 off.

Operating System

MacOS

Version Information

Cursor: 3.22.12 (stable)
VSCode version: 1.128.0
Commit: 3a92974361033b2051526321308c2740fe5912c0
Date: 2026-09-26T04:55:12.125Z
Chromium: 148.0.7778.280
OS: macOS 26.6.2 (25G83), arm64

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor